Are iterators and ranges going to co-exist?

[Andrei Alexandrescu]

On 07/19/2010 10:27 PM, PercentEwe wrote:
> == Quote from Peter Alexander (peter.alexander.au at gmail.com)'s article
>> What is the plan for this library? Will the std.algorithm start to use a
>> mixture of iterators and ranges (as it should, in my opinion)?
>
> As far as anyone not coming from C++ is concerned, ranges == iterators.
>
> Assuming you're coming from C++, ranges == a tuple consisting of a begin iterator
> and an end iterator. A great idea, I'll readily admit, but it's existed in Java
> for the past 15 years, and possibly in other languages before.

Agreed, with one amendment: Java et al. offer iterators for traversal 
only (strictly forward and access to only one element at a time), 
whereas STL offers traversaly PLUS access (bidirectional and random in 
addition to one-pass iteration and forward iteration). D's ranges 
combine the strengths of the two. I've seen similar comments a la, "Ah, 
D rediscovers Lisp's cdr or Python's iterator etc." and I think they're 
based on a misunderstanding.

Case in point: you can't reverse, sort, binary search, Boyer-Moore 
search, etc. etc. an iterator that focuses on traversal. Edit distance 
_might_ be implementable with Java iterators (they must implement 
clone() properly), but I couldn't find any such implementations that use 
iterators or for that matter any Java code that does correct edit 
distance on UTF-16 (I've seen only some that work with UCS-2) - witness 
to the underlying multi-layered confusion.

Essentially "classic" iterators are very algorithm-adverse and frame 
their users' mind into limited and stilted usage patterns.


Andrei