RFC on range design for D2

Andrei Alexandrescu SeeWebsiteForEmail at erdani.org
Wed Sep 10 05:33:21 PDT 2008


JAnderson wrote:
> 
> Hi Andrei,
> 
> I like the idea behind ranges.  I don't like C++'s / stl's long winded 
> syntax at all.  Its so large that it generally uses up several lines 
> along with several typedefs etc...  All that work just to iterate over 
> some data.  The longer things get the more error prone they get... how 
> many times have I put an begin when I meant to put end *sigh*.
> 
> However I currently disagree on this point.
> 
> Andrei Alexandrescu wrote:
>  >
>  > Fine. So instead of saying:
>  >
>  > foreach (e; c.all) { ... }
>  >
>  > you can say
>  >
>  > foreach (e; c) { ... }
>  >
>  > I think that's some dubious savings.
> 
> 
> I think its useful to have the implicit range conversion.  Consider 
> writing generic/template code.  Of course built in arrays could provide 
> the .all but then consider passing around ranges.  That would also mean 
> all ranges would also have a .all (could we go .all.all.all for 
> instance?).

There's no regression. There are containers and ranges. Containers have 
.all. Ranges don't.

I think you guys are making a good point; I'm undecided on what would be 
better. One not-so-cool part about implicit conversion to range is that 
all of a sudden all range operations spill into the container. So people 
try to call c.pop and it doesn't compile. (Why?) They get confused.

> I'm all for compile time checking however I think that 
> implicit .all (with of course an explicit option) will make it easy to 
> change a function that once took an object to take a simple range  Also 
> it would make it easy to change from one way of getting at a range to 
> another.
> 
> What about matrices?  They don't implement default .all, they would 
> provide like .col and .row.

Bidimensional ones that is :o).


Andrei


More information about the Digitalmars-d-announce mailing list