On Sat, Dec 27, 2008 at 2:31 AM, Andrei Alexandrescu <seewebsiteforem...@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 ;)