Should all enums be immutable?

[Don]

Trass3r wrote:
> Am 07.04.2011, 18:03 Uhr, schrieb Simen kjaeraas <simen.kjaras at gmail.com>:
> 
>> On Wed, 06 Apr 2011 21:42:35 +0200, Trass3r <un at known.com> wrote:
>>
>>> Am 06.04.2011, 20:40 Uhr, schrieb Simen kjaeraas 
>>> <simen.kjaras at gmail.com>:
>>>> Yup. In theory, any immutable Foo declared at module scope (and likely
>>>> also those at static class/struct scope) could be elided by the linker
>>>> if it not used anywhere, but Optlink does not do that.
>>>
>>> Ok, I guess the hack works by replacing every occurrence of the 
>>> constant identifier in the AST with the initializer part of "enum foo 
>>> = initializer;"?
>>>
>>> So there would be no reason to keep enum manifest constants if this 
>>> Optlink bug was fixed?
>>
>> Correct on both counts.
> 
> I'm still confused about this.
> Don't we need enum to have things like PI not consume memory?

No, the only thing it does it make it not take up space in the 
executable if it isn't used. And this is a linker issue.

> Which directly brings me to the following:
> http://www.digitalmars.com/d/2.0/enum.html states that enum ident = val; 
> is just shorthand for enum {ident = val}.
> Yet it suggests these are different things by calling only these special 
> cases "manifest constants" and stating that SUCH declarations are not 
> lvalues. Even though normal enums aren't lvalues either:
> 
> enum {a = 5, b}
> pragma(msg, &b);
> Error: constant 6 is not an lvalue
> 
> And also dmd handles them specially by treating enum as a storage class 
> (STC_manifest) in this case.

The terminology stuff is just because they're not enums. There is 
nothing about them which  would justify them being called an "enumerated 
type". But that's true of anonymous enums, enum { ident = val } as well.