On Sat, Dec 27, 2008 at 11:19 PM, Jarrett Billingsley <jarrett.billings...@gmail.com> wrote: > 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.
There is a little something nice about being able to use a pointer and iterator interchangeably for templated container algorithms. You lose that if ++iter can't be used to iterate your iterator. But working around it is not really that hard. One little incr(T)(ref thing) template and you're pretty much done. But ++foo is a concise syntax that conveys the meaning of what's happening pretty well, so it's a shame not to be able to use it on iterators. (Actually I don't really recall why it can't be used for iterators in D other than it forces you to use more runtime errors for bad args to +=. Was there anything more to it than that?) --bb
