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) -Larsi 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
