Operators without precedence

[jariji]

People often want to define unicode operators but it's not obvious or universal what their precedence should be. One idea I like is to define some operators without precedence, so that any ambiguity can be resolved by parentheses. It's obvious to the reader what is happening, and there is no need for different users to argue about what the precedence should be. Moreover, in the common case where only one operator call is used, there is no need for parentheses at all.

[stevengj]

Seems like this would have to be a 2.0 thing, if it's practical at all. We certainly can't change any of the existing infix operators to behave this way.

The basic issue here is that operator precedence is determined by the parser, which acts before any user definitions are loaded.

Closely related to #16985.

[JeffBezanson]

Also related: #18714
I think without more specifics this issue isn't actionable though. If there is a new proposed operator we don't yet parse, it can be added in this way, or if there are existing operators that should be changed (ergo 2.0) they should be listed explicitly.

[jariji]

One that might even be doable in 1.x is 2 .^ 1:5 which I can't imagine anybody doing on purpose.

As for 2.0, I think perhaps even most operators might be better off with this treatment absent some strong particularized argument for each one (such as the strong and universal convention on +-*/^() etc). Supporting code like w ⩋ x ⩍ y ⩎ z does no favors for readability, at least for me.

[putianyi889]

this question might be dumb, but what is preventing treating consecutive operators as a new operator?