T[new] misgivings

[Fawzi Mohamed]

On 2009-10-16 13:54:03 +0200, Max Samukha <spambox at d-coding.com> said:

> On Fri, 16 Oct 2009 02:53:20 -0700, Walter Bright
> <newshound1 at digitalmars.com> wrote:
> 
>> Don wrote:
>>> Max Samukha wrote:
>>>> // arrays are true reference types
>>>> int[new] a = [1, 2, 3];
>>>> b = a;
>>>> a.length = 22;
>>>> assert (a.length == b.length);
>>> 
>>> This makes perfect sense to me. The rule would be:
>>> If 'x' is T[new], then:
>>> x = y; _always_ copies y into a {length, capacity-specified block},
>>> unless it already is one. x is given a pointer to the start of that block.
>>> x[] = y[]; does a memcpy, regardless of whether y is a T[new] or a T[].
>> 
>> Right. Assignment of a reference type does not copy the values of what
>> is referred to. Only the reference is copied.
>> 
>> I think it would be very strange to have T[] behave like a reference
>> type (which it does now) and T[new] to behave like a value type.
> 
> By "true reference type", I meant:
> 
> struct ArrayRef
> {
>     Array* ptr;
> }
> 
> struct Array
> {
>    void* data;
>    size_t length;
>    // size_t capacity;
> }
> 
> The fat reference approach for arrays has sucked from day one (IMHO).
> 
> I think performance-critical code will use slices (read - ranges)
> anyway, so the additional allocation and indirection is not a big
> issue.

Yes exactly his is the most logically pleasing handling of resizable 
array, a resizable array is a ArrayRef (and the capacity there should 
not be commented out).

Obviously this has a cost (extra indirection to access data).

Fawzi