Mutable enums

[Steven Schveighoffer]

On Mon, 14 Nov 2011 03:27:21 -0500, Timon Gehr <timon.gehr at gmx.ch> wrote:

> On 11/14/2011 01:02 AM, bearophile wrote:
>> Jonathan M Davis:
>>
>>>> import std.algorithm;
>>>> void main() {
>>>>      enum a = [3, 1, 2];
>>>>      enum s = sort(a);
>>>>      assert(equal(a, [3, 1, 2]));
>>>>      assert(equal(s, [1, 2, 3]));
>>>> }
>>>
>>> It's not a bug. Those an manifest constants. They're copy-pasted into  
>>> whatever
>>> code you used them in. So,
>>>
>>> enum a = [3, 1, 2];
>>> enum s = sort(a);
>>>
>>> is equivalent to
>>>
>>> enum a = [3, 1, 2];
>>> enum s = sort([3, 1, 2]);
>>
>> You are right, there's no DMD bug here. Yet, it's a bit surprising to  
>> sort in-place a "constant". I have to stop thinking of them as  
>> constants. I don't like this design of enums...
>
> It is the right design. Why should enum imply const or immutable? (or  
> inout, for that matter). They are completely orthogonal.

There is definitely some debatable practice here for wherever enum is used  
on an array.

Consider that:

enum a = "hello";

foo(a);

Does not allocate heap memory, even though "hello" is a reference type.

However:

enum a = ['h', 'e', 'l', 'l', 'o'];

foo(a);

Allocates heap memory every time a is *used*.  This is counter-intuitive,  
one uses enum to define things using the compiler, not during runtime.   
It's used to invoke CTFE, to avoid heap allocation.  It's not a glorified  
#define macro.

The deep issue here is not that enum is used as a manifest constant, but  
rather the fact that enum can map to a *function call* rather than the  
*result* of that function call.

Would you say this should be acceptable?

enum a = malloc(5);

foo(a); // calls malloc(5) and passes the result to foo.

If the [...] form is an acceptable enum, I contend that malloc should be  
acceptable as well.

My view is that enum should only be acceptable on data that is immutable,  
or implicitly cast to immutable, and should *never* map to an expression  
that calls a function during runtime.

-Steve