Associativity is a property of the operator. The only way to do this is to use a right associative binary operator. I believe arrows fit this description, as do assignments.

Any idea where there’s a list of what Julia assumes for each operator?

I guess it doesn’t make much sense to me that Julia picks the assosciativity based on the unicode character. Shouldn’t I, the programmer defining what these operators mean, get to pick?

In order to define associativity the way you have, operators have to be parsed n-ary. Currently the only n-ary operators are + and * which are usually associative anyway. Unfortunately, even with n-ary parsing, mixing different operators with the same precedence will have the operator’s default associativity.

The reason operator associativity cannot be defined by the programmer in general (except via nary parsing, if applicable) is that the precedence of the operator must be known at parse time, whereas what the operator means is only knowable at runtime in general.

So I think really what I’d want is more operators to be parsed n-ary like + and * are (e.g. if my ⨳ above was included I’d be good). Which leads me to find https://github.com/JuliaLang/julia/issues/7368 where I’ll probably comment about this particular usefulness of parsing more things as n-ary, which doesn’t seem to have been mentioned there.

I wish there were more n-ary operators in Julia. There are cases where it’s more efficient to operate on all arguments at once instead of processing one after the other. Is there any hope that the parsing gets changed? For example, an infix operator op could be parsed to something like nary(op, x...) with default method foldl(op, x) or foldr(op, x). That would be similar to Base.literal_pow for powers with constant exponents.