Getting the string representing the enum value ~ Proposal

[John C]

"Justin C Calvarese" <technocrat7 at gmail.com> wrote in message 
news:e0vepu$es1$1 at digitaldaemon.com...
> Tom wrote:
>> kris escribió:
>>>  > Hope to hear the proposal again soon in the main newsgroup.
>>>
>>> You mean, perhaps Walter does not read D.Learn as much as the other 
>>> forums? Worth cross-posting, then, since there seems to be a general 
>>> feeling of "worthiness" on this one ... (see the rest of the thread)
>>
>> It's just that this kind of things must be heavily accepted in the main 
>> newsgroup before Walter takes it really on account. This is true at least 
>> with this kind of make-D-prettier proposals (It seems that way though I 
>> could be wrong).
>>
>> Tom;
>
> As far as I can tell, many people are in favor of x.nameof (and I'm one of 
> them). I haven't noticed that anyone is against this, but I think it's 
> more important for Walter to stamp out the known bugs and establish D 1.0.
>
> I'd be happy if x.nameof were part of D 1.1 though. ;)
>
> -- 
> jcc7

I'd prefer TypeInfo to be extended instead and allow typeid to take an enum 
member.

    enum Colour {
        CADET_BLUE,
        GOLDENROD,
        SEA_SHELL
    } // Upper-case enum members are recommended in the spec.
    char[] colorName = typeid(Colour.SEA_SHELL).name; // produces 
"SEA_SHELL"

Now, because no one would want to expose a string like "SEA_SHELL" to users, 
we might need to extend enums to optionally allow a string representation of 
its members at declaration:

    enum Colour {
        CADET_BLUE : "CadetBlue",
        GOLDENROD : "Goldenrod",
        SEA_SHELL : "SeaShell"
    }

While we're on the subject of operators, I think they need to made more 
consistent so that they're all callable in the same fashion. At the moment, 
we've got something.sizeof and something.mangleof but typeof(something) and 
typeid(something). I don't care which we settle on, but we should settle on 
one (I've a slight preference for something.typeid).

John C.