Julia: require space between `<` and unary operators?

[JeffBezanson]

This would allow us to add <- and <~ as operators (see e.g. https://github.com/JuliaLang/julia/issues/16985#issuecomment-354576381). x<-1 for comparing x to -1 is arguably not good style.

We could add ~> now, which would only break applying bitwise not to the > operator (which is pretty silly, although !> is a different story :) ).

[iblis17]

and maybe let DocumentFormat.jl do the work of enforcing on space or popup warnig?

[stevengj]

We have a lot of Unicode arrow operators now... do we really need another ascii-art “arrow”?

[oscardssmith]

I feel like this could lead to really hard to detect errors when writing things like x<-5 if <- means something like = 0

[ararslan]

FWIW <- was added almost exactly a year ago and was reverted exactly for the breakage it caused in simple and innocuous situations which in most languages are valid, e.g. 0<-1. In R <- is a holdover from APL-style arrow assignment in S, and many recent style guides for R discourage its use for assignment exactly due to this subtle confusion.

Given our multitude of Unicode arrows and the ease with which we allow entering Unicode symbols at the REPL and in editors, it seems unnecessary to me to add little gotchas in the parser just for the sake of having a couple of cute ASCII operators.

[JeffBezanson]

Interesting, there are still more Unicode arrows we need to add, in particular ⇜ and ⇝.

[stevengj]

See also #23224. The elements of the Arrows block that are currently not parsed as operators are ↕↖↗↘↙↜↝↞↟↡↢↥↧↨↩↪↫↬↭↯↰↱↲↳↴↵↶↷↸↹↺↻↼↽↾↿⇀⇁⇂⇃⇄⇅⇆⇇⇈⇉⇊⇋⇌⇍⇐⇑⇓⇕⇖⇗⇘⇙⇚⇛⇜⇝⇞⇟⇠⇡⇢⇣⇤⇥⇦⇧⇨⇩⇪⇫⇬⇭⇮⇯⇰⇱⇲⇳ ... several of these should probably be added to our operators list.

[JeffreySarnoff]

+1 for operator-izing ⇜ ⇝ ⇠ ⇡ ⇢ ⇣↥↧

[StefanKarpinski]

The left and right arrows are easy enough, the up and down ones need an appropriate precedence. We can always add more arrow operators in 1.x versions so this is not urgent.

[stevengj]

@StefanKarpinski, adding these arrow operators in 1.x would be a breaking change. e.g. ⇜ is currently parsed as an identifier because U+21dc is in category So (Symbol, Other).

[JeffBezanson]

I added several of those in #25360

[StefanKarpinski]

I was under the impression that we were treating characters that we might want to make into operators (like arrows) as invalid. Of that not the case, should we do that?

[JeffBezanson]

Yes, on master the whole arrows block was made invalid characters, some of which have now become operators. Identifying other characters that we might make into operators unfortunately has to be done one at a time in general.

[stevengj]

Right, sorry, I wasn't checking master. On master the remaining non-operator arrows are ↖↗↘↙↟↡↥↧↨↭↯↰↱↲↳↴↵↶↷↸↹↺↻↾↿⇂⇃⇅⇈⇊⇑⇓⇕⇖⇗⇘⇙⇞⇟⇡⇣⇤⇥⇦⇧⇨⇩⇪⇫⇬⇭⇮⇯⇰⇱⇲⇳, and these are currently all invalid in identifiers.