Operator overloading through UFCS doesn't work

Timon Gehr timon.gehr at gmx.ch
Wed Oct 17 08:43:41 PDT 2012


On 10/17/2012 01:51 PM, Maxim Fomin wrote:
> 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.


Members do not cause conflicts with free functions.
Alias this takes precedence as it is a member of the type.
What is the issue?


More information about the Digitalmars-d-learn mailing list