Array literals MUST be immutable.

Don nospam at nospam.com
Thu Feb 18 05:00:55 PST 2010


Michel Fortin wrote:
> On 2010-02-18 03:10:47 -0500, Don <nospam at nospam.com> said:
> 
>>> Well, array literals are not always constants. Take this for instance:
>>>
>>>     int[] array = [x, y, z];
>>>
>>> This array literal does not have an "immutable source" as you call it.
>>
>> This is the issue. The syntax sugar you get from not requiring an 
>> "immutable source" comes at a very high price.
>>
>>> Should it really require a ".dup" to get a mutable array? How 
>>> efficient would it be?
>>
>> What it does at the moment is insert a hidden .dup at all times. And 
>> the performance is terrible. Really, really terrible. Roughly 100 
>> times worse than you expect.
>> At the moment, [1, 2, 3] is basically transformed into something like 
>> makeArray(1,2,3);
> 
> I agree the performance is terrible because of the often unnecessary 
> heap allocation.

It's not just the heap allocation. The values are also recalculated.

> But assigning a literal to an immutable array should be 
> easy to special-case in the compiler so that it doesn't do an 
> unnecessary copy.

Yes, but that doesn't work in the general case. It cannot be done for 
anonymous literals.
Also you can't force an array literal to be CTFEd.

> Also, they're quite useful. How would you write the code above without 
> them?
> 
>     int[] array;
>     array.length = 3;
>     array[0] = x;
>     array[1] = y;
>     array[2] = z;

Including the library implementation:

T[] toArray(T)(T[] values...)
{
     return values.dup;
}

int[] array = toArray(x,y,z);

Mutable array literals achieve almost nothing.




More information about the Digitalmars-d mailing list