In article <e0pqn7$1ngo$1@digitaldaemon.com>, kris says...
>
>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.
>
>Thoughts?

It gets my vote - but there are a few kinks to work out.

For instance, how does this compare to .classname or TypeInfo.toString()?

I'd imagine that it would follow the same behavior as .mangleof (possibly all the way around), with respect to aliases and typedefs.  Templates might be kind of sticky though -- any ideas on that?

- EricAnderton at yahoo

pragma wrote:
> In article <e0pqn7$1ngo$1@digitaldaemon.com>, kris says...
> 
>>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.
>>
>>Thoughts?
> 
> 
> It gets my vote - but there are a few kinks to work out.
> 
> For instance, how does this compare to .classname or TypeInfo.toString()?

For classes, I think it would be equivalent to .classname (since that returns a char[] of the class name). I suspect TypeInfo.toString() is a different kettle of fish, since it deals with type information instead of names per se?

> 
> I'd imagine that it would follow the same behavior as .mangleof (possibly all
> the way around), with respect to aliases and typedefs.  Templates might be kind
> of sticky though -- any ideas on that?

I think it would, as you say, follow the same behaviour as .mangleof ~ a  simple concept with simple rules; Had imagined .nameof would simply give you an equivalent name for anything that you can legitimately dereference. Regarding templates, does .mangleof do anything unexpected?

In article <e0rsbe$1hdm$1@digitaldaemon.com>, kris says...
>
>pragma wrote:
>> In article <e0pqn7$1ngo$1@digitaldaemon.com>, kris says...
>> 
>>>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.
>>>
>>>Thoughts?
>> 
>> 
>> It gets my vote - but there are a few kinks to work out.
>> 
>> For instance, how does this compare to .classname or TypeInfo.toString()?
>
>For classes, I think it would be equivalent to .classname (since that returns a char[] of the class name). I suspect TypeInfo.toString() is a different kettle of fish, since it deals with type information instead of names per se?
>
>> 
>> I'd imagine that it would follow the same behavior as .mangleof (possibly all the way around), with respect to aliases and typedefs.  Templates might be kind of sticky though -- any ideas on that?
>
>I think it would, as you say, follow the same behaviour as .mangleof ~ a
>  simple concept with simple rules; Had imagined .nameof would simply
>give you an equivalent name for anything that you can legitimately dereference. Regarding templates, does .mangleof do anything unexpected?

Well, you can only name-mangle a template instance, since they technically don't exist otherwise.  The result is often a *very* complicated mangling that is a composite of the template name, namespace and all the type arguments that comprise it.  So the .nameof might have to be something simple, and less useful and unique than the .mangleof rendition.

class Foo(X){}
const char[] bar = Foo!(int).mangleof; // should probably just yield "Foo"

- EricAnderton at yahoo

This is something that has been discussed before. Don't know why it has been rejected though.

This feature I'd love to see implemented in D. All these kind of little details makes D very attractive for C/C++ programmers (some of them wish there was a prettier syntax for C++ and they see D as just that, in the beginning of course). Believe me I know people that loves this kind of stuff, though it would be just a little detail for some points of view, it's not just about saving a few lines of code, it's also about nicer and prettier code (avoids duplicating stuff).

Hope to hear the proposal again soon in the main newsgroup.

Regards,
--
Tom;

kris escribió:
> Ben Gardner wrote:
>> I've done that "the hard way" in C.
>> Here's an example in D:
>>
>> /////
>> import std.stdio;
>> import std.string;
>>
>> enum X {
>>   Apple,
>>   Bat,
>>   Car,
>> }
>>
>> char [][] X_names = [
>>    X.Apple : "Apple",
>>    X.Bat   : "Bat",
>>    X.Car   : "Car",
>> ];
>>
>> char [] get_X_name(X e)
>> {
>>    if ((e >= X.min) && (cast(int)e < X_names.length) &&
>>        (X_names[e] !is null)) {
>>       return X_names[e];
>>    }
>>    return ("invalid");
>> }
>>
>> X get_X_id(char [] name)
>> {
>>    for (int idx = 0; idx < X_names.length; idx++) {
>>       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
>>          return cast(X)idx;
>>    }
>>    return cast(X)-1;
>> }
>>
>> void main(char [][] args)
>> {
>>    for (int i = -1; i < 4; i++)
>>    {
>>       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
>>    }
>>
>>    char [] name = "bat";
>>    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
>> }
>> ////
>>
>> Running this produces the output:
>> -1 = 'invalid'
>> 0 = 'Apple'
>> 1 = 'Bat'
>> 2 = 'Car'
>> 3 = 'invalid'
>> id for 'bat' is 1
>>
>> Ben
>>
>> Hasan Aljudy wrote:
>>
>>> say I have an enum
>>>
>>>    enum X
>>>    {
>>>     A,
>>>     B,
>>>     C
>>>    }
>>>
>>> and I have
>>>
>>>    void someFunc( X e )
>>>    {
>>>     //.. some code
>>>    }
>>>
>>> I want to print the value of 'e' but I don't want to get a number!! I
>>> want to get a string that represents it. i.e. A or B or C
>>>
>>>
>>>    void someFunc( X e )
>>>    {
>>>       toString(e);
>>>       e.string;
>>>       e.value;
>>>       //or something like that ..
>>>    }
>>>
>>> Is there any such thing in D?
>>>
> 
> 
> 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.
> 
> Thoughts?

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



Tom wrote:
> This is something that has been discussed before. Don't know why it has been rejected though.
> 
> This feature I'd love to see implemented in D. All these kind of little details makes D very attractive for C/C++ programmers (some of them wish there was a prettier syntax for C++ and they see D as just that, in the beginning of course). Believe me I know people that loves this kind of stuff, though it would be just a little detail for some points of view, it's not just about saving a few lines of code, it's also about nicer and prettier code (avoids duplicating stuff).
> 
> Hope to hear the proposal again soon in the main newsgroup.
> 
> Regards,
> -- 
> Tom;
> 
> kris escribió:
> 
>> Ben Gardner wrote:
>>
>>> I've done that "the hard way" in C.
>>> Here's an example in D:
>>>
>>> /////
>>> import std.stdio;
>>> import std.string;
>>>
>>> enum X {
>>>   Apple,
>>>   Bat,
>>>   Car,
>>> }
>>>
>>> char [][] X_names = [
>>>    X.Apple : "Apple",
>>>    X.Bat   : "Bat",
>>>    X.Car   : "Car",
>>> ];
>>>
>>> char [] get_X_name(X e)
>>> {
>>>    if ((e >= X.min) && (cast(int)e < X_names.length) &&
>>>        (X_names[e] !is null)) {
>>>       return X_names[e];
>>>    }
>>>    return ("invalid");
>>> }
>>>
>>> X get_X_id(char [] name)
>>> {
>>>    for (int idx = 0; idx < X_names.length; idx++) {
>>>       if ((X_names[idx] !is null) && (icmp(X_names[idx], name) == 0))
>>>          return cast(X)idx;
>>>    }
>>>    return cast(X)-1;
>>> }
>>>
>>> void main(char [][] args)
>>> {
>>>    for (int i = -1; i < 4; i++)
>>>    {
>>>       writef("%d = '%s'\n", i, get_X_name(cast(X)i));
>>>    }
>>>
>>>    char [] name = "bat";
>>>    writef("id for '%s' is %d\n", name, cast(int)get_X_id(name));
>>> }
>>> ////
>>>
>>> Running this produces the output:
>>> -1 = 'invalid'
>>> 0 = 'Apple'
>>> 1 = 'Bat'
>>> 2 = 'Car'
>>> 3 = 'invalid'
>>> id for 'bat' is 1
>>>
>>> Ben
>>>
>>> Hasan Aljudy wrote:
>>>
>>>> say I have an enum
>>>>
>>>>    enum X
>>>>    {
>>>>     A,
>>>>     B,
>>>>     C
>>>>    }
>>>>
>>>> and I have
>>>>
>>>>    void someFunc( X e )
>>>>    {
>>>>     //.. some code
>>>>    }
>>>>
>>>> I want to print the value of 'e' but I don't want to get a number!! I
>>>> want to get a string that represents it. i.e. A or B or C
>>>>
>>>>
>>>>    void someFunc( X e )
>>>>    {
>>>>       toString(e);
>>>>       e.string;
>>>>       e.value;
>>>>       //or something like that ..
>>>>    }
>>>>
>>>> Is there any such thing in D?
>>>>
>>
>>
>> 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.
>>
>> Thoughts?
> 
> 

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;

> 
> 
> Tom wrote:
>> 
>> kris escribió:
>>
>>> Ben Gardner wrote:
[snip]

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

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;
> 
>>
>>
>> Tom wrote:
>>>
>>> kris escribió:
>>>
>>>> Ben Gardner wrote:
> [snip]

I don't even read D.learn, and I imagine that is the case of a lot of others as well.

"Justin C Calvarese" <technocrat7@gmail.com> wrote in message news:e0vepu$es1$1@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.

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