Operator overloading

[Andrei Alexandrescu]

Jarrett Billingsley wrote:
> On Sat, Dec 27, 2008 at 2:31 AM, Andrei Alexandrescu
> <SeeWebsiteForEmail at erdani.org> wrote:
>>>> 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).
> 
> I got the impression from your argument that you thought that without
> an appropriate method of overloading the increment operator, it's not
> possible to duplicate the _syntax_ of STL-style iterators.  My
> response is - who cares?  I don't think of iterators as "pointers that
> can be incremented," and I doubt anyone who doesn't have a C++
> background thinks of them that way either.  It seems that the
> semantics of STL iterators can be implemented with methods just as
> well.
> 
> If that's not what you were arguing - that is, if you're arguing that
> C++'s operator overloading is somehow more expressive and allows you
> to implement something that can't be implemented with method calls -
> then I will put my foot in my mouth ;)

Well I overstated my point, sorry. The nice thing about overloading ++ 
is that you can use the same algorithms with built-in types and 
user-defined types. You are, however, right that defining various 
functions such as increment and decrement for built-ins and also 
user-defined types would obviate the need for syntactically consistent 
operators.

Andrei