RFC on range design for D2

JAnderson ask at me.com
Wed Sep 10 21:13:53 PDT 2008


Andrei Alexandrescu wrote:
> 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.
> 

Just to be clear then.  Say you write something that works on arrays and 
objects.  Then you write:


void Foo(T)(T t)
{
	...
	foreach (auto i; t.all)
	{

	}
	...
}

Now I realize I want to use that function with a range as well as an 
object (its a template after all).  Well if .all isn't regressive then I 
can't.  Of course if .all was implicit then I might have written:

void Foo(T)(T t)
{
	...
	foreach (auto i; t)
	{

	}
	...
}

But then again, .all is still available so there's still a chance a 
coder might not realize that its better to use the implicit value.  I'm 
beginning to think regressive would be useful either way.

Note of course generic code does not just apply to templates.  It also 
applies when I want to change a variable to a different type.  If .all 
is required (and non-regressive) then I have to go to all the places 
that value is used and change it.  Its the same reason auto is so awesome.

Of course .all adds an extra function you'd need to implement for custom 
ranges, but it could always be in the "range" mixin.

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

Of course :) being a games programmer, we know of only speak of one 
matrix type.

Just kidding.

> 
> 
> Andrei


More information about the Digitalmars-d-announce mailing list