www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - stringof Bug?

reply "Janice Caron" <caron800 googlemail.com> writes:
Do we count this as a bug, or not?

    class T(int N)
    {
    }

    writefln(T!(1).stringof);

This writes "T", not "T!(1)".

This might seem trivial, but it took me hours to debug a problem I
had, whereby I was passing a load of type names into a mixin and then
using stringof to turn that input into valid D code, so of course when
I did

    mixin M(T!(1));

it all fell over. The error message was something like "class T(int)
used as a type", and the location of the error was deep inside the
mixin. After much aggravation, I found the workaround, which was was
to do

    class A : T!(1) {}
    mixin M(A);

So, is that a real bug, or are my expectations just too high?
Oct 19 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

 Do we count this as a bug, or not?
 
     class T(int N)
     {
     }
 
     writefln(T!(1).stringof);
 
 This writes "T", not "T!(1)".



 So, is that a real bug, or are my expectations just too high?


There are quite a few stringof bugs. I think this one hasn't been reported
before.
BTW, did you try typeof(T!(1)).stringof ?
Oct 19 2007
parent reply "Janice Caron" <caron800 googlemail.com> writes:
 BTW, did you try typeof(T!(1)).stringof ?


Not at the time, but I have now. Surprisingly, it compiles! (What's
the type of a type?)

It prints "void".
Oct 19 2007
parent reply Don Clugston <dac nospam.com.au> writes:
Janice Caron wrote:

 BTW, did you try typeof(T!(1)).stringof ?


 
 Not at the time, but I have now. Surprisingly, it compiles! (What's
 the type of a type?)


Now that's an interesting question...
I've found that sticking typeof() in these sorts of things sometimes gives you 
useful information.

 
 It prints "void".


Hmm. 'void' frequently seems to be returned in lieu of a compile error.
typeof(a) is always void when a is an alias.

Something I've noticed is that x.stringof and (x).stringof are completely 
different. So (T!(1)).stringof is something else I'd try.
In some of the early releases, .stringof behaved very differently; it performed 
semantic analysis on the expression, and returned a Lisp-y mass of parentheses.
Did you know that .stringof was originally an Easter egg? (One of many <g>). It 
was documented in the spec, but not listed in the change log. IIRC, Walter said 
that it was too buggy to announce.
Oct 19 2007
parent reply 0ffh <spam frankhirsch.net> writes:
Don Clugston wrote:

 Something I've noticed is that x.stringof and (x).stringof are 
 completely different. So (T!(1)).stringof is something else I'd try.


I can second that. I remember once I had a templated struct and
needed sizeof. "(StructT!(int)).sizeof" worked for me while the
"StructT!(int).sizeof" didn't. Maybe "." binds closer than "!"?

Regards, Frank
Oct 19 2007
parent reply Don Clugston <dac nospam.com.au> writes:
0ffh wrote:

 Don Clugston wrote:

 Something I've noticed is that x.stringof and (x).stringof are 
 completely different. So (T!(1)).stringof is something else I'd try.


 
 I can second that. I remember once I had a templated struct and
 needed sizeof. "(StructT!(int)).sizeof" worked for me while the
 "StructT!(int).sizeof" didn't. Maybe "." binds closer than "!"?


I think you're right. It also seems to be right-associative, so a.b.c.d ALWAYS 
parses as a.(b.(c.d)).
1.23.stringof
doesn't work (that's in Bugzilla).
Oct 19 2007
parent 0ffh <spam frankhirsch.net> writes:
Don Clugston wrote:

 1.23.stringof doesn't work (that's in Bugzilla).


You mean like the lexer finds "23.stringof" and then
it cannot make any sense of the "1." in front of it?
Wouldn't happen with a packrat parser... ;-)

Regards, Frank
Oct 19 2007