Please, notnotin, that’s nogood.
2 Likes
The solution is obvious: introduce !n and !sa.
15 Likes
What is ComposedFunction inherited the fixity of its inner function? That would make !in infix, but keep !isdigit, for example, prefix. Would that work? I know that fixity is something that’s decided at parse time, so obviously the parser needs to be modified to take care of this. But semantically, this would be easy to explain.
How about aint? Ok, that was a joke (thought Julia could have been the first programming language with more diverse English [operator]): Ain't - Wikipedia
The use of ain’t is a continuing subject of controversy in English
[and not_aint, naint? !aint…?]
3 Likes
I considered ainta, but then thought, no, jokes like that wear old after a while (e.g. eye, who, …).
They may be the least objectionable, but this does not mean that it is worth introducing special cases for them either.
Ideally, surface syntax is a few general rules that compose well, with the minimum number of special cases. The fact that a special case is not very objectionable or is minimally beneficial is not enough to justify it, the bar should be much higher.
2 Likes
The objectional part is actually, imo, that a !<op> b doesn’t work, while !<op>(a, b) does. Even though it’s hard to make this work for every case (due to != et al), I think special-casing !in and !isa would provide a better 'illusion of consistency than the status quo.
2 Likes
if aInt aint Int this aint int, chief.
11 Likes
You are wrong:
julia> :( for i in itr end )
:(for i = itr
#= REPL[1]:1 =#
#= REPL[1]:1 =#
end)
julia> :( (x for x in itr) )
:((x for x = itr))
(sorry, I’m sure this isn’t what you meant 
)
Fans of infix composition might be interested in
Note that adding new alphabetic operators is not something we can add in 1.x because it breaks code that might already have identifiers with those names. eg, I might have a variable called notin, so adding an operator called notin would break my code.
I personally like the unicode operators. There are many unicode infix operators that do not have non-unicode alternatives, so it’s best to get used to using them. eg: \subseteq ⊆, \nsubseteq ⊈, \subsetneq ⊊, \supseteq ⊇, \approx ≈, \napprox ≉
That’s not a problem for !in, though.
1 Like
An infix operator like ∈ in y !∘∈ xs could be allowed without problem, and I think 1 !∘∈ [3,4] is good syntax.
Edit: this isn’t actually what I meant. I’ll try again later.
I’m not sure that’s right… For example Julia 1.10 has the new tanpi function. This doesn’t break code that used tanpi as variable name: if you define tanpi before using the tanpi function, your definition takes precedence. Would it be different for an infix operator?
That’s pretty obscure and confusing. It’s also a mishmash of a set operator a logical operator (in programming notation), and a function composition operator. Just to express a set operation. They don’t blend well, imo. I think this requires too broad knowledge to understand, in addition to being quite messy.
1 Like
Also who would want to write 1 !∘∈ [3,4] instead of 1 ∉ [3,4]?
6 Likes
Since notin would have a mechanism very similar to in and
julia> function in(x,y)
5
end
in (generic function with 1 method)
julia> 7 in [8,9]
5
julia> in("a","b")
5
julia>
You are probably right (which actually surprised me as well).
Edit: I do still prefer !in or only supporting the Unicode variant
2 Likes
If the actual problem proposed by this topic is “having a more compact way of writing !(x in y)”, then I think that simply defining and exporting ∉ with the semantics above is the best solution. We have the Unicode symbol, it is simple to type, and is conventional enough.
It’s already defined and exported 
5 Likes