Infix operator definition syntax needs documentation

[tkelman]

I had no idea we support the below syntax for defining infix operators. AFAICT it's not in the manual, and before f07485f I don't think it was in any tests either. Am I the only one who was unaware of this?

julia> import Base.+
julia> immutable wrapper
           val
       end
julia> a::wrapper + b::wrapper = wrapper(a.val + b.val)
+ (generic function with 172 methods)
julia> wrapper(1) + wrapper(2)
wrapper(3)

[KristofferC]

Didn't know about that! Cool though.

[toivoh]

It comes as a natural consequence of the fact that

a::wrapper + b::wrapper = wrapper(a.val + b.val)

is parsed the same way as

+(a::wrapper, b::wrapper) = wrapper(a.val + b.val)

but I actually seem to recall a discussion about explicitly disallowing it a long time ago, since it can cause inadvertent method definitions at unexpected occasions (almost thought that we had).

[StefanKarpinski]

IIRC, Alan posted a bug email about this since he'd done something like a + b = 2 or something and was surprised when there was no error since this just defines a fallback method for +.

[ararslan]

I actually seem to recall a discussion about explicitly disallowing it a long time ago, since it can cause inadvertent method definitions at unexpected occasions (almost thought that we had).

A hearty +1 to disallowing assignment using infix notation. If you accidentally use a + b = 2 instead of a + b == 2 you're in for an odd surprise, which is what I assume happened to Alan. I doubt this syntax was being used much in any serious manner so it would likely be a pretty undistruptive change.

[JeffBezanson]

I like that this syntax works. And I generally dislike the design strategy of "looking around for things to ban".

[ararslan]

I don't think it's about looking for things to ban so much as the principle of least surprise. For me, anyway.

[tkelman]

It's more error-prone than it is useful.

In my head it feels like LHS and RHS of assignments should have slightly different rules, it runs against my intuition sometimes when they don't.

[JeffBezanson]

The argument that somebody might be confused or make a mistake is another one I usually find unconvincing. If you're confused, the right response is to look at the reasons actually in play and see if they make sense. I'm also concerned about piling up dozens of special cases in order to fix each instance where somebody was confused once. It seems unlikely to lead to a coherent result.

[tkelman]

"the reasons actually in play" are that the parsing happens the same on both sides of an assignment. That simplifies the parser but doesn't result in clearer semantics for users of the language IMO. This is also terribly underdocumented, undertested, and virtually unused such that people who've been using the language for years don't even realize it works because they subconsciously think it shouldn't.