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