John C wrote:
[snip]
> 
> 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"

There's a potential problem there. TypeInfo is typically generated for each new type; not for each instance of a type. What you suggest would seem to require a specific TypeInfo for each instance rather than just for each type (to expose each instance name). That would be somewhat wasteful: wouldn't want that to happen for, say, every int variable that I wish to .nameof upon;

x.nameof does not have that issue at all.

Typeinfo also has a bit of a problem with verbosity: I currently have to opine "typeid(typeof(MyVarName))" to the compiler, just to get TypeInfo. This starts to look like C++ <g>

private static Attribute[] map =
[
{typeid(typeof(Tuple.label)),       Tuple.label.offsetof},
{typeid(typeof(Tuple.quantity)),    Tuple.quantity.offsetof},
{typeid(typeof(Tuple.description)), Tuple.description.offsetof},
];



> 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"
>     }

It could be said that complicates things for minimal gain? Why not just give them reasonable names to begin with?

enum Colour {CadetBlue, GoldenRod, SeaShell};

where Colour.CadetBlue.nameof == "CadetBlue"

BTW: it's a nice change to see the English spelling of Colour :)


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

Couldn't agree more. I much prefer the .property approach

Don Clugston wrote:
> 
>>>> I'll propose that a new property be added, somewhat like the .mangleof property. Instead, a .nameof property would simply return the lexical token for the named entity. Doesn't matter whether it refers to a struct, class, some attribute thereof, enum types or members, whatever ... the x.nameof should just return a char[] of the respective name.
> 
> 
> I would love to have something which could convert enum values to strings; but I think there are some interesting possibilities to consider.
> 
> An approximation to .nameof can already be synthesised using template tricks with .mangleof. It does not, however, work for enum values, and doesn't really work for local variables (because local symbol names can't be alias parameters -- except for mixins).
> 
> One issue that I can see with this proposal is, what name should be returned? My template implementation provides symbolnameof, qualifiednameof, prettynameof, and manglednameof.
> 
> It also allows you to get the original name from an alias template parameter, allowing something like:
> 
> template debugPrint (alias a) {
> void debugPrint()
> {
>    writefln("The value of ", qualifiednameof!(a), " is ", a);
> }
> 
> only works as a mixin unfortunately. Usage:
> 
> void func()
> {
>   int x = 7;
>   mixin debugPrint!(x);
>   debugPrint();
> }
> 
> // output:
> The value of test.func.x is 7
> 
> ------------
> Obviously much too ugly to be much use right now, but I think there are some tantalising possibilities there, which should be considered in a nameof proposal.

Was kinda' hoping you'd have a go at this;

I'd expected x.nameof to return an unqualified name (what you called the symbol name?). The reasoning was twofold: it should be very easy to implement consistently, and one could perhaps construct a fully-qualified name by concatenation (via ~) of component symbols? The compiler would probably fold them, since each would be the equivalent of a const char[]? Or, maybe an x.fullnameof might appear later? Anyway, the goal was to expose something simple to implement and easy to use. As usual, you've opened up a whole bunch of other useful possibilities <g>

"kris" <foo@bar.com> wrote in message news:e0vvs2$1b27$1@digitaldaemon.com...
> John C wrote:
> [snip]
>>
>> 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"
>
> There's a potential problem there. TypeInfo is typically generated for each new type; not for each instance of a type. What you suggest would seem to require a specific TypeInfo for each instance rather than just for each type (to expose each instance name). That would be somewhat wasteful: wouldn't want that to happen for, say, every int variable that I wish to .nameof upon;

This is true. I was trying (but failed - sigh) to make it consistent with how we already retrieve class names and such. I guess, without full introspective capacilities, D needs another way to get partial type information at low cost.

>
> x.nameof does not have that issue at all.
>
> Typeinfo also has a bit of a problem with verbosity: I currently have to opine "typeid(typeof(MyVarName))" to the compiler, just to get TypeInfo. This starts to look like C++ <g>
>
> private static Attribute[] map =
> [
> {typeid(typeof(Tuple.label)),       Tuple.label.offsetof},
> {typeid(typeof(Tuple.quantity)),    Tuple.quantity.offsetof},
> {typeid(typeof(Tuple.description)), Tuple.description.offsetof},
> ];
>
>
>
>> 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"
>>     }
>
> It could be said that complicates things for minimal gain? Why not just give them reasonable names to begin with?
>
> enum Colour {CadetBlue, GoldenRod, SeaShell};
>
> where Colour.CadetBlue.nameof == "CadetBlue"

I must say, I never really liked the Java-style upper case naming convention which D seems to have adopted for enums. Pascal casing looks much better than HEY_IM_TALKING_TO_YOU.

Since providing a TypeInfo for everything would be wasteful, and at the risk of performing a complete about-face, let's have the following availble for everything:

.nameof
    Returns the unqualified name of a declared symbol, eg "EnumMember"
.fullnameof
    Returns the qualified name of a declared symbol, eg
"module.Enum.EnumMember"

>
> BTW: it's a nice change to see the English spelling of Colour :)
>
>
>> 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).
>
> Couldn't agree more. I much prefer the .property approach

kris wrote:
> 
> Typeinfo also has a bit of a problem with verbosity: I currently have to opine "typeid(typeof(MyVarName))" to the compiler, just to get TypeInfo. This starts to look like C++ <g>
> 

It also feels to me as bit of unnecessary verbosity. I think typeid should work with variables as parameters too, such that:
  typeid(somevar) == typeid(typeof(somevar))


> 
> BTW: it's a nice change to see the English spelling of Colour :)
> 
> 

The "English" spelling? You mean British... or is American not English? :P

-- 
Bruno Medeiros - CS/E student
http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D