Revised RFC on range design for D2

[Sergey Gromov]

Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org> wrote:
> In wake of the many excellent comments and suggestions made here, I made 
> one more pass through the draft proposal for ranges.
> 
> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> There are some comments in red illustrating some uncertainties (not 
> all), and the names of the primitives have been updated. Bicycle shed 
> galore! But don't forget to comment on the reactor as well :o).

I've got a heap of virtual sticky notes all over my monitor while 
reading the edited version, so here they are.

*)
done/next/head thing got even more confusing.  Range is not a process, 
you cannot be done with it.  If you call a spade a spade, then done() is 
actually a safe, guarded prefetch, head is, well, sort of what it claims 
to be, and next() just relaxes done's guard.

The look ahead/fetch next approach was much more intuitive.  I don't 
understand why you dropped it.  I remember you saying that Bill 
convinced you it was wrong but I either missed the arguments themselves 
or hadn't understood them.

*)
How do you enforce noncopyable/release semantics over a range?  I don't 
think D got any means for that.  Also if an input range is a class 
passed by reference, will you allow it?

*)
before() is valid for a single-linked list, forward iterators should 
support it.

*)
You've replaced tail with toe because people may think tail could 
contain many elements.  But it doesn't pair well with head, and besides, 
if I split a list in the middle I'd call the halves a head and a tail 
which form a logical pair.  Maybe you consider tip-toe, or top-toe, from 
the top of my head? ;)

*)
A typo: in Output range sample:
	for (; !src.done; src.head)
should be
	for (; !src.done; src.next)

*)
next() is specified to return a value, but reduce() is not.  This is 
probably a typo.  I'd prefer them both be implemented as (done(), head) 
and (reduce(), toe) respectively, but I don't know what your intention 
was.

*)
Still uncertain support for shrink-on-read, no support for shrink-on-
write and slicing forward and bidirectional ranges.  Are they going into 
a library?