Getting the string representing the enum value ~ Proposal

[kris]

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>