On 04/29/2012 12:12 PM, Nick Sabalausky wrote:
> "Timon Gehr"<timon.g...@gmx.ch> wrote in message
> news:jnj92m$306m$1...@digitalmars.com...
>> On 04/29/2012 08:35 AM, Nick Sabalausky wrote:
>>
>>> it's just a series of manifest
>>> constants. The fact that they're grouped doesn't even have any semantic
>>> consequence, as far as I'm aware.
>>
>> The only differences are that they don't occupy their own namespace and
>> they don't define their own type. But non-anonymous enums are _just a
>> bunch of manifest constants_ as well!
>
> No, they're not. Non-anon enums *contain* a bunch of manifest
constants. But
> what non-anon enums *are* is a type. Anon enums are not a type at all. I
> think that's a significant difference.
I see that way as well. I have a section titled "enum values that are
not of an enum type" at http://ddili.org/ders/d.en/enum.html:
[quote]
sometimes it may not be natural to come up with enum type names just to
use named constants. Let's assume that a named constant is needed to
represent the number of seconds per day. It should not be necessary to
also define an enum type for this constant value. All that is needed is
a constant value that can be referred to by its name. In such cases, the
type of the enum and the value parentheses are not specified:
enum secondsPerDay = 60 * 60 * 24;
[/quote]
> Of course, my biggest issue by far is with the name "enum".
Agreed. It became a bad name as soon as any value other than a number
could be an enum value (or "member").
> Non-anon enums
> can reasonably be thought of as enumerations (except for bitfields, but I
> think those should be handled differently from enums anyway). But
anon-enums
> are just plain not enumerations, period. If we weren't calling them all
> "enum", then I would have much, much less problem with the syntax we
have.
> And yea, I get the whole "What's in a name?", but "enum" is just a
> colossally *terrible* name for this. It's worse than when "immutable" was
> called "invariant".
Ali
