Operator overloading

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Fri, Dec 26, 2008 at 11:20 PM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>> 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 does, however, introduce a nice naming scheme for naming
> "meta-methods", that is, methods which are called indirectly to
> overload certain language structures.  opApply is an example of such a
> method which doesn't truly have a corresponding operator, and I'm sure
> there could be other other methods for other language constructs,
> existing or theoretical.  (though I'm sure you'll agree opApply's
> behavior could use a rehaul too)
> 
>> This is the vomit in the fat lady's cleavage that shows just how bad the
>> wine turned out to be.
> 
> That has to be one of the most disgusting metaphors I've ever heard ;)
> 
>> 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.
> 
> I suppose most people who _aren't_ coming from C++ (*cough* like me
> *cough*) won't be terribly unhappy about this situation.

I'm not sure how that computes. The particular notion has little to do 
with C++ and is rather fundamental, so not grokking it should motivate 
one to look into it (as opposed to being glad for not knowing).

Andrei