Will uniform function call syntax apply to operator overloads?

[Jonathan M Davis]

On Tuesday, October 12, 2010 15:53:38 Simen kjaeraas wrote:
> Tomek Sowiński <just at ask.me> wrote:
> >> As long as operator overloading is defined the way it is, it should work
> >> like that, yes.
> > 
> > Funny. I remember asking this not too long ago and got no as an answer.
> > 
> > :)
> 
> I'm not saying it will. But as long as operator overloading is defined as
> a rewrite of e.g. a + b => a.opBinary!"+"( b ), and uniform function call
> syntax is defined as a rewrite of a.opBinary!"+"( b ) =>
> opBinary!"+"( a, b ), and there are no extra, special rules in play, I
> would be surprised if it does not work.
> 
> By this I mean, it would be anti-feature if it did not work, as the
> compiler would have to be more complex to not support it than to support
> it.

That would depend on what order it did things. If it replaced a.func() with 
func(a) before it replaced a + b with a.opBinary!"+"(b), then it wouldn't be 
more work at all. It would just naturally not work. If, on the other hand, the 
overloaded operators were replaced first, then it could turn a.opBinary!"+"(b) 
into opBinary!"+"(a, b).

However, I don't think that you can create freestanding operator overloads. As I 
understand it, they have to be part of a type (though I could be wrong). 
Assuming that that were the case, the uniform function syntax would be 
irrelevant because you couldn't legally declare an overloaded operator function 
which would work with it.

Personally, I do _not_ think that overloaded operators should work with uniform 
function syntax, if for no other reason than because it doesn't actually look 
like the uniform function syntax does. There is no . operator directly involved. 
And I don't see any real value in overloaded operators which aren't part of the 
type. Unlike C++, I don't think that we have any operators where having an 
overloaded operator function be a member function is a problem (the classic 
operators with that problem being >> and <<).

- Jonathan M Davis