Mutable enums

[Steven Schveighoffer]

On Wed, 16 Nov 2011 16:47:58 -0500, Simen Kjærås <simen.kjaras at gmail.com>  
wrote:

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

Solved via library:

auto b = a.deepdup;

-Steve