Operator overloading

Jarrett Billingsley jarrett.billingsley at gmail.com
Sat Dec 27 06:19:55 PST 2008

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

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 ;)

More information about the Digitalmars-d mailing list