Are iterators and ranges going to co-exist?

[PercentEwe]

== 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.

The example Andrei gave about implementing find(range,value)? It's similar in
nature to this problem with C# enumerables (iterators are implementations of
IEnumerable in C#):
http://ayende.com/Blog/archive/2010/06/10/checking-for-empty-enumerations.aspx

Not surprisingly, the fix is identical: create an enumerable consisting of the
element you popped and the enumerable that you've partially consumed.

As for space usage, well, sometimes ranges can give you an improvement, and in the
worst case, a range is a struct with begin and end C++ iterators as its members.
It's a space improvement unless you don't actually need to iterate through
anything, in which case, why are you using an iterator?

> In the thread on improving std.algorithm.find, there were mentions of
> making find (or some findFirst) that returned a single element. Would
> this be an iterator, or a single value range?

Again, why are you using an iterator? Or a range, or enumerable, or what have you?
I guess it's a tad easier than: bool tryFind(range, element, out position); or
returning a struct containing a success flag and the element found.