T[new] misgivings

[Denis Koroskin]

On Fri, 16 Oct 2009 18:30:24 +0400, Andrei Alexandrescu  
<SeeWebsiteForEmail at erdani.org> wrote:

> Lutger wrote:
>> Just to understand it:
>>  int[new] a;
>> int[new] b;
>>  a = [1,2,3];
>> b = a;
>>  In your book, the last statement would copy contents of a into b and  
>> b.ptr != a.ptr while according to walter, b would rebind to a?
>
> Well no.
>
> In the case above b would rebind to a, which is consistent with:
>
> int[new] a = [1, 2, 3];
> void fun(int[new] b) { ... }
> fun(a); // does not copy a
>
> I am not concerned about assigning one array to another. I'm more  
> concerned about assigning an array literal to an array.
>
>
> Andrei

So, the real question is, what's the type of an array literal?

If it's T[new] then you must reassign a reference to be consistent:

int[new] a = arrayLiteral;
int[new] b = a; // reassign reference
foo(arrayLiteral); // a reference passed

Else, invoke opAssign. And its semantics is not clear.

I'm in favor of removing hidden allocations and making compile-time  
literals immutable:

immutable(int)[] a1 = [1, 2, 3];

In case of compile-time literal assignment you can't just re-assign a  
reference (because it's immutable), so opAssign should take care of it:

int[new] a2;
a2 = [1, 2, 3]; // rewritten as a2.opAssign([1, 2, 3]);

Since there should be now hidden allocation, values should be overwritten.  
And there are two options:

1) Strict assignment:

# assert(a2.length == [1, 2, 3].length);
# a2[0..3] = [1, 2, 3];

2) Auto-expand (but not shrink!):

# if (a2.capacity > [1, 2, 3].length) throw new Exception("...");
# a2.capacity = [1, 2, 3].length;
# a2[0..3] = [1, 2, 3];

Why not shrink? Because I believe the following test should be valid:

a2 = [1, 2, 3];
assert(a2 == [1, 2, 3]); // they must match if the statement above succeeds