On Tuesday, October 12, 2010 15:53:38 Simen kjaeraas wrote: > Tomek Sowiński <[email protected]> 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
