Mutable enums

[Simen Kjærås]

On Wed, 16 Nov 2011 21:00:16 +0100, Steven Schveighoffer  
<schveiguy at yahoo.com> wrote:

> On Wed, 16 Nov 2011 14:26:57 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:
>
>> On 11/16/2011 02:22 PM, Steven Schveighoffer wrote:
>>> On Tue, 15 Nov 2011 13:45:02 -0500, Timon Gehr <timon.gehr at gmx.ch>  
>>> wrote:
>>>
>>>> Note that this is an explicit allocation:
>>>>
>>>> int[] a = [1,2,3]; // just as explicit as a NewExpression
>>>>
>>>> Only the enums "hide" it sometimes, but actually you should know the
>>>> involved types.
>>>
>>> As I've said, there are already ways to explicitly allocate memory. A
>>> suggested replacement for this is:
>>>
>>> int[] a = array(1, 2, 3);
>>>
>>> And you could always do:
>>>
>>> int[] a = [1, 2, 3].dup;
>>>
>>> Nobody complains about having to do:
>>>
>>> char[] a = "hello".dup;
>>>
>>> I don't see why we couldn't do the same for all array literals.
>>>
>>
>> Because 'immutable' behaves nicely on built-in value types, but not on  
>> arbitrary reference types.
>
> string is a reference type.  We hear no complaints about strings being  
> stored in ROM and the type of literals being immutable.

immutable(int[][]) a = [[1]];
int[][] b = a.dup; // Fails.

The problem is with more than a single layer of indirection.