Bill Baxter wrote:
On Sat, Dec 27, 2008 at 9:42 AM, The Anh Tran <trthe...@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
