On 28 November 2012 15:07, tn <n...@email.com> wrote: > On Tuesday, 27 November 2012 at 21:16:41 UTC, Walter Bright wrote: > >> On 11/27/2012 9:51 PM, Manu wrote: >> >>> There's another you missed: >>> enum X = 10; >>> I would have imagined this would be semantically identical to E.A/E.B, >>> but the compiler seemed to view this as distinct in my experiments. >>> >> >> Those are not enums, they are manifest constants. What distinguishes a >> manifest constant from, say: >> >> const Y = 11; >> >> is that no storage is allocated for X, and X's address cannot be taken. >> > > What distinguishes manifest constants from literals? Aren't manifest > constants just literal aliases? That is, if the following did work > > alias Y = 11; > > wouldn't that be exactly same as > > enum Y = 11; > > Perhaps using "alias" instead of "enum" would make the meaning clearer? >
Interesting concept, but as far as the docs suggest, it's like this: (In fear of dragging a conversation in a bug report to the NG (probably more appropriate here)...) enum E { X = 10 } // enum definition enum { X = 10 } // anonymous enum enum X = 10; // sugar for anon enums with a single value This is how it's documented, and it makes perfect sense to me. I like it. In fact, I found this concept super-endearing when I initially started using D a lot over C++. All X's above should be identical (albeit the first has a named scope), they're all enum values. E is the type here, it's the only thing that an instance may be created of. X, equally in all cases, is just a constant value. I'm not sure how the language syntax distinguishes it from a literal (I'm not sure why it would have to), but it does seem the compiler distinguishes each of these X's from each other in some cases.