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
next sibling 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 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?)

I've found that sticking typeof() in these sorts of things sometimes gives you useful information.
 
 It prints "void".

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
prev sibling parent "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