Operator overloading through UFCS doesn't work

[Timon Gehr]

On 10/14/2012 09:01 AM, Maxim Fomin wrote:
> On Saturday, 13 October 2012 at 19:50:02 UTC, Timon Gehr wrote:
>> On 10/13/2012 06:02 PM, Maxim Fomin wrote:
>>> ...
>>> Different groups of people have different mind and same things produce
>>> different sense on them. From my point of view operator overloading
>>> methods are special functions and not treating them as candidates for
>>> UFCS does make more sense.
>>
>> I do not understand how an operation that happens to be called '+' is
>> fundamentally different from an operation that is called 'add'.
>
> The first one is an operator, which sometimes, may be rewritten to
> function call, the second one is a function call.
>

What is the difference between an operator and a function call? Is it
important?

int add(int a, int b){ return a+b; }
// or conversely (not valid syntax):
int (int a)+(int b){ return add(a,b); }


>>> Even if you convince in your opinion,
>>> language addition without applied purposes makes no benefit.
>>
>> I guess the functionality could be achieved in DMD mostly by removing
>> code. (Code for good error messages excluded!)
>
> I don't understand what you are trying to say. Anyway, you can write a
> pull request and propose it at github. It would be interesting to see
> reaction of others.

Built-in types shouldn't be special except maybe that the parser
recognises related keywords.

It should go like this:

a + b             => a.opBinary!"+"(b); // opBinary_r woes left out,
                                         // but would require treatment
a + b             => __add(a,b); // if a and b of built-in type
a.opBinary!"+"(b) => __add(a,b); // if a and b of built-in type

Where __add(a,b) is the representation of an AST node of a built-in add
operation involving operands a and b.

All the code in DMD that supposedly tries to make up for this kind of
inconsistencies (and sometimes fails, because it does not catch all the
ways the language features interact) can be gotten rid of.