Should all enums be immutable?

[Nick Sabalausky]

"Rainer Schuetze" <r.sagitario at gmx.de> wrote in message 
news:ind21j$1si5$1 at digitalmars.com...
>
> Don wrote:
>> Jonathan M Davis wrote:
>>> Enum values cannot be altered. It is an error to try and assign a value 
>>> to an enum. However, the value of an enum isn't really const or 
>>> immutable. It's copied every time that the enum is used. This is fine in 
>>> cases where the enum is a value type, but it's problematic when the enum 
>>> is a reference type. I believe that the classic example is if you have 
>>> an AA which is an enum. You copy _the entire_ AA every time it's 
>>> referenced. But it's not just AA's. Normal arrays have the problem too.
>>>
>>> Given that the value of enum must be known at compile time and given 
>>> that it cannot be changed, why aren't enums all immutable? What's gained 
>>> by making so that every reference to an enum is replaced by its value 
>>> rather than actually referencing an immutable value? In most cases, it 
>>> could still be replaced by the value (since it's a constant) if that's 
>>> more efficient. And in the case of reference types, it would actually 
>>> act like a reference type.
>>>
>>> So, I ask, should enums just all be made automatically immutable instead 
>>> of having the current replace when referenced semantics? Is there a good 
>>> reason _not_ to make all enums immutable?
>>
>> Yes. The ONLY reason those manifest constants exist at all, is so that 
>> they don't exist at run time. They have no address. Any case where taking 
>> a reference to them works, is a compiler bug.
>>
>> Almost all existing enum arrays or AAs are bugs.
>> For example, if you have a lookup table which should be used at runtime, 
>> it should ALWAYS be defined as const or immutable, not as an enum.
>
> Unfortunately, you currently get the same performance penalty with const 
> or immutable arrays as with enum: 
> http://d.puremagic.com/issues/show_bug.cgi?id=4298

/me looks through all his D code for any enum/immutable/const arrays...

Even once it gets fixed for immutable/const, I hope it still gets fixed for 
enum, too. It'd be a real pain to have to think about "enum or immutable?" 
every time I need a fixed named value. And I can imagine that also causing 
problems for metaprogramming:

template foo(T, alias val)
{
    // Oops!! Sometimes needs to be immutable!
    // Gotta split this into two template overloads...
    enum T foo = val;
}

My understanding was that the point of enum (the manifest constant enum) was 
to serve as *the* de facto way to do fixed named values because of a 
particular limitation of trying to do the same with immutable.