Revised RFC on range design for D2

[Andrei Alexandrescu]

bearophile wrote:
> Andrei Alexandrescu:
>> http://ssli.ee.washington.edu/~aalexand/d/tmp/std_range.html
> 
> I have re-read the page again, and I am now starting to understand its contents. When I'll understand 90-95% of that page then I think it's dumbed enough for most programmers ;-)
> 
> In lines like:
> t=r.before(s)
> 
> I suggest to add a more natural spacing:
> t = range.before(s)

That's a good point. At the time I wrote that document, inserting the 
spaces would really mess up the table by breaking the expression. Since 
then I fixed the style, but not (yet) the document.

> But maybe adding an "all" to that method name you it can show better that it generates a new range:
> t = range.allbefore(s)

So many good proposals for names have been put forth, it will be 
definitely impossible to find one set of names that will please 
everybody. So everybody, please expect to be disappointed. I *do* need 
to do some actual work instead of getting ready to do it.

> This is one of the functions shown in that page:
> 
> // Increments all elements in a range
> void bump(R)(R r)
> {
>     for (; !r.done; r.next)
>     {
>         ++r.head;
>     }
> }
> 
> But that's not readable. This improves readability 5X (note current instead of head and isdone instead of done):
> 
> /// Increments all items of a Forward range
> void bump(R)(R range) {
>     while (!range.isdone) {
>         range.current++;
>         range.next();
>     }
> }

Maybe 5X is a bit exaggerated, but if the point was that good names are 
important, I entirely agree.

One problem with the done/current approach to naming is that it does not 
dovetail well with non-temporal collections (I'm computing a fresh 
range; how come I have to query whether it's "done"? And what's 
"current" to an array?) But then there are problems with, and advantages 
of, any naming scheme ever mentioned here. At the end of the day I'll 
have to choose one. Again, everybody, prepare to be disappointed.

> If the D language will keep the foreach(), then where possible I suggest to add a version that uses foreach() too:
> 
> /// Increments all items of a Forward range
> void bump(R)(R range) {
>     foreach (ref item; range)
>         item++;
> }

Walter will have foreach automatically detect and use ranges.

> In that document you can also show 1 example for all functions/ methods/ attributes, like r.after(s), etc.
> 
> I think that good names and some sugar may make this stuff usable (not easy, but usable).

I agree that good names and some sugar are helpful. Now, if you could 
tell how I can make things actually easy, that would be huge. I hoped 
three functions would be easy. True, defining their semantics in 
excruciating detail will not be as easy, but it will have the advantage 
to be rigorous enough to produce reliable implementations.


Andrei