Operator overloading

[Andrei Alexandrescu]

Bill Baxter wrote:
> On Sat, Dec 27, 2008 at 9:42 AM, The Anh Tran <trtheanh at gmail.com> wrote:
>> aarti_pl wrote:
>>> Andrei Alexandrescu pisze:
>>>  > We're trying to make that work. D is due for an operator overhaul.
>>>  >
>>>  > Andrei
>>>
>>> Is there any chance that we get possibility to overload "raw operators",
>>> like in C++? I think that they may coexist with currently defined operator
>>> overloads with simple semantic rules, which will not allow them to work
>>> together at the same time.
>>> ..........
>>> BR
>>> Marcin Kuszczak
>>> (aarti_pl)
>> Me also have a dream :D
>>
>> <Daydream mode>
>> class Foo
>> {
>>        auto op(++)(); // bar++
>>        auto op(++)(int); // ++bar
>>
>>        op(cast)(uint); // cast(uint)bar // opCast
>>        auto op(())(int, float); // Foo(123, 123.456) // opCall
>>
>>        auto op(+)(Foo rhs); // bar1 + bar2
>>        auto op(+=)(int); // bar += 1234;
>>        auto op(.)(); // bar.xyz // opDot
>>
>>        Foo op([][][])(int, char, float); // bar[123]['x'][123.456]
>>
>>        auto op([..])(); // i = bar2[] // opSlide
>>        auto op([..])(int, int); // bar[1..10]
>>
>>        auto op([..]=)(float); // bar[] = 12.3 //opSlideAssign
>>        auto op([..]=)(int, int, float); // bar[1..3] = 123.4
>> }
>> </Dream>
> 
> When I suggested this kind of thing long ago, Walter said that it
> encourages operator overload abuse, because it suggests that  + is
> just a generic symbolic operator rather than something that
> specifically means "addition".  That's why D uses "opAdd" instead.
> It's supposed to encourage only creating overloads that follow the
> original meaning of the operator closely.  That way when you see a+b
> you can be reasonably sure that it means addition or something quite
> like it.

I think that argument is rather weak and ought to be revisited. It's 
weak to start with as if writing "+" in a D program hardly evokes 
anything else but "plus". What the notation effectively achieved was put 
more burden on the programmer to memorize some names for the 
already-known symbols. I think the entire operator overloading business, 
which started from a legitimate desire to improve on C++'s, ended up 
worse off.

> It also goes hand-in-hand with design decisions like
> defining ++x to be x+=1, which means that in D it's impossible to make
> ++x mean something distinct from incrementing by 1.

This is the vomit in the fat lady's cleavage that shows just how bad the 
wine turned out to be. For iterators, increment is quite different from 
addition of an arbitrary number, so what D managed to do was effectively 
to cripple iterators. The standard library will use ranges with named 
functions so it avoids the issue, but if someone wants to define 
STL-style iterators they won't be able to.

> With C++ you can
> make ++x have whatever meaning you want.  It can do something
> completely different from x+=1.  The idea is that such freedom just
> makes code harder to read.

That sounds nice, but on the face of it I haven't heard of much code 
suffering from the problem.

> Currently I don't think it makes much difference either way.  The only
> real advantage I see to the alternate syntax is that it can be perhaps
> a little easier to remember.  But I also I don't think Walter's idea
> about naming following usage does anything to stop someone like Downs
> from using opDiv to do something completely different from division.
> It probably never even occurred to Downs that Walter was trying to
> prevent him from abusing opDiv by naming it opDiv instead of
> operator(/).  The people who are likely to abuse operators are
> precisely those who aren't likely to be daunted by mere naming.
> 
> But anyway, just so you know, that's why D does things the way it
> does.  So that means to see your dream come true you first have to
> convince Walter that it's a dream worth having. :-)

The story is quite lame, so it may be worth scrutinizing it. Let's make 
D operators not suck. Wanna?


Andrei