Private enum members + Descent

[Lars T. Kyllingstad]

Yigal Chripun wrote:
> On 26/10/2009 12:07, Lars T. Kyllingstad wrote:
>> Yigal Chripun wrote:
>>> personally I'd like to see D enums replaced by Java style enums which
>>> make more sense to me. D enums are even worse than C enums since you
>>> can write:
>>> enum foo = "text";
>>>
>>> which to me looks very similar to:
>>> auto cat = new Dog;
>>
>>
>> I agree that enum is a horrible keyword to use for declaring manifest
>> constants. In my opinion the D developers are sometimes a bit too afraid
>> of introducing new keywords, and this is one of the consequences.
>>
>> Personally, I think this would be a better scheme:
>>
>> const: manifest constants, no storage (like const in D1, enum in D2)
>> readonly: used for a read-only view of mutable data (like const in D2)
>> immutable: truly immutable data (like now)
>>
>> -Lars
> 
> i don't think we need to add more options, I think we need to remove 
> options.
> there should be only two types, const and mutable.
> manifest constants should be a linker optimization and immutable is only 
> relevant as part of a concurrency model and even then there's no need 
> for a separate keyword.
> 
> immutable objects are shared objects where only the owner is allowed to 
> modify it and only if it's done in a thread-safe way (synchronized with 
> locks, lock-free algorithms).
> void foo() {
> // can be optimized away (transformed into a manifest constant)
> // taking address of var is illegal
> const var = 42;
> // allocated on the heap and you can pass it's address around
> auto bar = new const int(42);
> }


I was going to protest: "But what about const struct members? Should the 
size of the following struct depend on whether the compiler determines 
it can optimize by turning its const member into a manifest constant?"

   struct Foo { const int bar = 123; }

But then I decided to actually try it with the current DMD2, and found 
that the compiler does just that!

   writeln(Foo.sizeof);    // Prints "1", not "4"

   Foo foo;
   auto p = &foo.bar;   // Error: constant 123 is not an lvalue

What's going on? Is this intended behaviour?

-Lars