Operator overloading through UFCS doesn't work

[Tommi]

On Monday, 15 October 2012 at 09:33:23 UTC, Maxim Fomin wrote:
> ---foo.d---
> struct A
> {
>    int i;
>    alias i this;
> }
> ---bar.d---
> int opUnary(string T)(A a) { ... }
> ...
> {
>   ++a;
> }
> -----------
> I. i is incremented, opUnary is not called. However opUnary 
> matches better to the actual type and if it were a method, it 
> would be called - another special issue in the language which 
> breaks usual logic. And if you declared opUnary in bar.d when 
> alias this was absent in foo.d and later added - hijacking also 
> occurs but now it happens from another side. Bad.

Let's talk about the semantics of the word "hijacking" as it 
relates to this discussion. Here's my take on it:

Let type T have some inherent functionality F. That is, 
functionality F cannot be removed from T without making changes 
to the module file where type T is defined. Then, if some other 
functionality F' overrides (replaces and modifies) F, it is said 
that F' "hijacks" F.

If I apply this definition to your example, we see that the free 
function opUnary in bar.d is *not* part of struct A's inherent 
functionality. Therefore, by adding later that alias this in A's 
definition, we are *not* hijacking anything.

Furthermore, if that free function opUnary was defined in foo.d 
instead, it would be an inherent part of A's functionality. Then, 
by adding later that alias this in A's definition, we would be 
*changing* A's functionality. But that's not hijacking, because 
we're making the change in the module file where A is defined. 
That's not hijacking, that's just changing the inherent 
functionality of your own user-defined type.