Operator overloading through UFCS doesn't work

[Timon Gehr]

On 10/17/2012 01:32 PM, Maxim Fomin wrote:
> On Wednesday, 17 October 2012 at 11:00:05 UTC, Timon Gehr wrote:
>> On 10/16/2012 05:57 PM, Maxim Fomin wrote:
>>> ...
>>>
>>> At NG discussion it may look nice to define some type and then add
>>> operator overloading methods
>>
>> Operator overloading is not magic, so your statement can be shortened to
>>
>> ... and then add methods
>>
>> Which is still not correct, because that is not what UFCS does.
>>
>
> It is not correct as long as you cavil at lexis, however the statement
> has room for correction.
>

In a discussion it is crucial that both parties agree on a common set
of terms and definitions. Otherwise agreement cannot be detected.

>>> but as soon as you import some other
>>> modules, authors of which also consider UFCS operators a good idea,
>>
>> Who has stated that? It just does not make sense to explicitly ban
>> them, as they are not special.
>
> Who stated that they should be "explicitly banned"?

Well, you did, if I got that right:

On 10/13/2012 06:02 PM, Maxim Fomin wrote:
> From my point of view operator overloading methods are special functions
> and not treating them as candidates for UFCS does make more sense.

(Explicitly banning UFCS operators is the same thing as not treating
rewritten operators as candidates for UFCS.)

> I explained potential problem in previous posts.
>

Yes, several times, but to me the argument still looks similar to the
following (note that only the 'counter argument' part is related to
this discussion):

Issue: the 'body' keyword is not used enough to warrant keyword status,
parsing could succeed without making it a full keyword.

Proposed solution: make 'body' a valid identifier that is only
recognised as special where it is expected to occur.

Main counter argument: Two people might define a symbol using the newly 
available 'body' identifier, which can cause symbol conflicts.

Do you agree with this reasoning, and if not, what is the fundamental
difference between this and the point you are trying to convey?


>>> everything breaks including namespace conflict
>>
>> The usual disambiguation procedures apply. (Which are broken in DMD at
>> the moment, because module-scope private symbols can cause conflicts.)
>>
>> Infix operators are not special. It is just notation.
>>
>>> as well as loosing
>>> ability to manipulate that type within built-in expression as well.
>>
>> I did not get that.
>
> Again, the problem is in conflict between different declared operator
> overloading functions across different modules.

Can you explain the usage of the term 'built-in' in this context?