Mutable enums

[Jonathan M Davis]

On Monday, November 14, 2011 04:03:54 so wrote:
> Trying to remember the discussions on digitalmars.D regarding
> enum/immutable. There were contradicting opinions.
> You ask the same question at two different times, you get at least two
> different answers, especially on this matter.
> There was/is not a consensus on how it works or should work.
> 
> While i think enum/immutable are not same thing. Because with enum you
> mean it is a compile time value and compile time only, but immutable might
> rely on runtime initializers. So it differs here. This just means enum
> gives you more guaranties, not less.
> 
> enum a = 5;
> immutable b = 6;
> a = 3;
> b = 3;
> 
> If the above code is invalid for both enum and immutable, so should the
> "in-place" sort case. I understand how it works, but it doesn't make any
> sense why it should work that way.

It works exactly as it's designed to work. There are people who disagree with 
how it's designed, but it works exactly as designed. The above is invalid, 
because you can't assign to an enum - it's not a variable - and you can't 
assign to an immutable variable. sort works with an enum because you're 
passing it a valid array which is _not_ immutable. It's a new array just as if 
you'd passed it the enum's value directly. That may be surprising to some, but 
it's exactly as designed and is not a bug. If you think that it should work 
differently, then you're arguing against the current design, which is a 
completely different discussion.

- Jonathan M Davis