Operator overloading

Bill Baxter wbaxter at gmail.com
Fri Dec 26 17:22:31 PST 2008


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.  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.  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.

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. :-)

--bb



More information about the Digitalmars-d mailing list