enum - auto

[Timon Gehr]

On 11/14/2011 11:33 AM, Simen Kjærås wrote:
> On Mon, 14 Nov 2011 11:14:02 +0100, so <so at so.so> wrote:
>
>> Auto and immutable.
>> Can we please put an end to this issue?
>> I remember a few discussions, never a complete answer, but many
>> contradicting answers.
>>
>> 1. Is enum (its current usage) still a temporary hack to a technical
>> limitation on immutable?
>
> Yes and no. Enum was chosen due to limitations in the linker, which made it
> impossible to weed out unused constants. The linker is free to remove
> unused
> constants, but DMD's linker will not do so. Perhaps in the future, it will.
>

I guess this is not a problem on Linux. I still find the enum storage 
class to add significant value to the language.

>
>> 2. Can or Will immutable replace enum? (Not that i want such a change)
>
> Enum is now an established part of the language, and even if such were
> possible,
> it is not going to happen.
>
>
>> 3. Isn't enum a higher order immutable, which is guarantied to be a
>> compile time constant?

static immutable variables are also guaranteed to be compile time 
constants. enum and immutable are not too tightly related.


>
> One could think of it as such, yes. That hardly gives much advantage over
> immutable, though. The main feature of enum is that it takes up no space
> in the
> result binary.
>

There are other important differences. enums are always treated like 
values, even if their type has reference semantics. (basically, that 
means their value is just copied each time they are referenced.) This is 
necessary to guarantee their constancy without restricting operations on 
their values.

Furthermore writing

enum x = foo(); // CTFE'd/compile time constant

is much more convenient than having to write

static immutable x = foo(); // CTFE'd/compile time constant

Even when ignoring the fact that the second one infects x with the 
'immutable' type qualifier.