∈ in for loops?

[eschnett]

I wanted to use the syntax

for i ∈ 1:10

but discovered that Julia doesn't allow this. Given that in and ∈ are identical when used as operators, it would be nice to allow this syntax as well.

[johnmyleswhite]

This seems a little risky to me: to me, epsilon implies a set operation, not one that involves order.

[eschnett]

Same as in?

[kmsquire]

+1 for allowing this syntax

[johnmyleswhite]

That's a good point. I suppose my objection would lead to the unrealistic idea that using in is bad.

[stevengj]

+1 ... it seems weird to allow x ∈ collection as a synonym for x in collection, but not for x ∈ collection.

[malmaud]

Is there a reason #11223 was closed? It seems like fair game if we're going to start aliasing unicode symbols to keywords.

[stevengj]

@malmaud, \mapsto is a separate issue; we have already aliased ∈ to in, so the meaning of ∈ in Julia is not up for debate.

[malmaud]

Well, I thought maybe some of the motivation for closing the \mapsto issue was a reluctance to ever have a unicode symbol usable as a keyword, in which case the fact that ∈ already maps to the operator in (but not the syntactic keyword in) already might not have been relevant.

[simonster]

-1 from me. IMO, we already have one too many ways to write this construct, since for x in a and for x = a do the same thing. In this case it doesn't even save a character to use ∈, since you could use =. It's just Unicode for Unicode's sake.

[malmaud]

You could have said that about using ∈ for the operator in. But now that that ship has sailed, wouldn't this bring more consistency?

[simonster]

I think there was a better argument for using ∈ for in, since it's a notation people actually use in papers, not something we're adding for its own sake. This is just providing a third, less common way to do something you can already do, which imposes some code readability cost on new users. I'd honestly prefer removing the for x in a syntax if we're worried about consistency here.

[stevengj]

I am worried about consistency. It's quite hard to explain to people why you can test inclusion by x ∈ X or x in X, but you can loop with for x in X but not for x ∈ X.

As for eliminating for x in X, I think that ship has sailed.

[nalimilan]

Actually, I think Stefan recently said that the for x = X syntax (a legacy from MATLAB) was the most likely to go away, if one of them is deprecated at some point. +1 to in and ∈.

[toivoh]

I think using ∈ in for loops is also pretty close to how it is used in papers. Sure, your regular applied math paper doesn't contain any actual for loops, but quite often statements that should be considered for each x ∈ X etc.

[jakebolewski]

I also don't really like this proposal either. This just touches on a pet peeve were people use Unicode when we have perfectly acceptable and universally understandable (editable!) ascii equivalents. We really should just have one for loop syntax that everyone uses. The for loop in is a special form, so it's not equivalent to aliasing an operator like all other unicode defaults.

[stevengj]

@jakebolewski, we already have a Unicode equivalent for in (as an operator). Are you proposing removing that? And if not, doesn't the syntactic inconsistency of the two in variants bother you?

Why is changing the for loop "not equivalent to aliasing an operator? Of course, it is implemented differently (but the implementation is trivial, see my PR). But from a user perspective, does it really look different? Imagine yourself explaining to a physics student "Well, you can use ∈ here instead of in because it is an operator, but not in loops because that is a special form," and they respond WTF is this "special form" stuff and why is Julia forcing me to learn it?

Just because something is a special form and we can make it different doesn't mean that we shouldn't try to harmonize special forms with other parts of the language.

[hayd]

+1 to allowing for x ∈ X and deprecating (in the future) for x = X.

This just touches on a pet peeve were people use Unicode when we have perfectly acceptable and universally understandable (editable!) ascii equivalents.

I think this ship has sailed too, unicode .

[KristofferC]

deprecating (in the future) for x = X.

If our main goal is to increase the number of confused matlab programmers on the mailing list, I'm sure we can do better ;)

[johnmyleswhite]

I'm also in favor of deprecating for x = X.