RFC: naming for FrontTransversal and Transversal ranges

[Robert Jacques]

On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke <rainerd at eldwood.com>  
wrote:

> Robert Jacques wrote:
>> Again, D array's are structs with reference semantics. This isn't a
>> pro/con either way.
>
> The D1 dynamic array type does not have reference semantics, nor does it
> have value semantics.
>
> void f(int[] a) {
>   a.length = 1;
> }
>
> auto a = [];
> f(a);
> assert(a.length == 0);
>
>>>   - No long distance dependencies.
>>
>> Well, if I can't copy it, then I have to use ref everywhere, which is
>> functionally equivalent to reference semantics. I think you've just
>> proved the counter-point.
>
> Given a value type 'T', you have the guarantee that no two variables of
> type 'T' can alias each other.  This guarantee is preserved when the
> type 'T' is non-copyable.
>
> An argument of type 'ref T' can obviously alias a variable of type 'T'.

Okay, if T is not copyable, then I _must_ pass it as ref T, everywhere.  
Which is reference semantics.

>>>   - RAII.
>>
>> Can be done with structs or classes. Also see point 1. So, this isn't a
>> pro/con either way.
>
> The D1 dynamic array type does not support RAII.

There are two parts to D's arrays. One a struct 2 words long, the other is  
a chunk of ram. The first part is RAII, the second part is not possible,  
since D doesn't allow dynamically sized memory allocation on the stack.  
And basically all dynamic data structures have to do some heap allocation.  
I had thought you were talking about the difference between have the  
managing head be a struct of a class. (See scope classes)