Should all enums be immutable?

[Don]

Nick Sabalausky wrote:
> "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.

No. It's just a workaround for an optlink bug: manifest constants that 
are never used, still get put into the executable.

By default, you should use const, not enum. You should forget that enum 
manifest constants even exist.