Operator overloading through UFCS doesn't work

[Maxim Fomin]

On Wednesday, 17 October 2012 at 11:11:26 UTC, Timon Gehr wrote:
> On 10/14/2012 09:14 AM, Maxim Fomin wrote:
>> On Sunday, 14 October 2012 at 07:01:30 UTC, Tommi wrote:
>>> Actually, it seems that alias this has precedence over UFCS. 
>>> So, a
>>> free function opUnary wouldn't ever suit better than an 
>>> actual method
>>> opUnary of the thing referred to by that alias this.
>>
>> http://dpaste.dzfl.pl/d0a4431d
>>
>> Free function doesn't suit better than actual method. The 
>> issue is
>> absence of the actual method.
>>
>> opUnary method has priority over alias this, which does make 
>> sense
>> because alias this is chosen only when it is impossible to 
>> apply
>> operation over A type. If this request is approved and 
>> compiler has
>> opUnary definition outside type (which suits better then alias 
>> this)
>> such function would hijack alias this. If not, there is a new 
>> case when
>> something is going special than at usual cases and only for 
>> the purpose
>> of writing operator overloading methods outside the body of 
>> the type.
>
> The goal must be to get rid of all special behaviour that can 
> result in
> strange interactions.
> Add the suitable operator function templates to built-in types. 
> Always
> rewrite operators to operator function calls. Problem solved.
> ...

You have a struct with alias this to int without overloaded 
operators. It (say, struct.d) contains code with structure 
increments. Some other module (say bob.d), which import the 
structure, defines function supposed to overload opUnary. If 
operators are always rewritten to function calls, now function 
should be called in module bob.d, as well as in struct.d if they 
are compiled together. It certainly not what author of struct.d 
expected. The case can be even more interesting, if alias this in 
struct.d were absent at a time when bob.d was written and at some 
point of future Bob is updating his sources.