RFC: naming for FrontTransversal and Transversal ranges

[Rainer Deyke]

Robert Jacques wrote:
> On Sat, 02 May 2009 19:11:11 -0400, Rainer Deyke <rainerd at eldwood.com>
> wrote:
>> 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.

When passing arguments, (possibly const) ref is a reasonable default.  I
don't care about how arguments are passed.  I care about aliasing
between variables, especially member variables.

With reference semantics, two variables of type T can reference each
other.  With non-copyable types, they cannot.

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

It's meaningless to talk about RAII in the context of the "struct" part
of a D1 dynamic array, since it doesn't manage any resources.  If I
place a variable of a RAII type in a D1 dynamic array, it is not
properly destroyed when the array goes out of scope.  Therefore D1
dynamic arrays do not support RAII.

Stack versus heap allocation is an orthogonal issue.


-- 
Rainer Deyke - rainerd at eldwood.com