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)

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


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();
    }
}


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++;
}

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

Bye,
bearophile

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