• drug (7/7) Oct 05 2017 https://run.dlang.io/is/8LbmzG
• Adam D. Ruppe (21/27) Oct 05 2017 stringof is a static debugging aid, just a string that kinda
• drug (2/36) Oct 05 2017 Thank you, Adam!

drug <drug2004 bk.ru> writes:

https://run.dlang.io/is/8LbmzG

1) why .stringof and typeid() is equal logically and different in fact? 
What is difference between them? Is it that stringof compile time and 
typeid runtime things? Anyway wouldn't it be better they will equal both 
logically and literally?
2) Where do these attributes come from? I mean `pure nothrow  nogc 
 safe` except ` property` that I set explicitly?

Adam D. Ruppe <destructionator gmail.com> writes:

On Thursday, 5 October 2017 at 14:59:10 UTC, drug wrote:
 1) why .stringof and typeid() is equal logically and different 
 in fact? What is difference between them? Is it that stringof 
 compile time and typeid runtime things? Anyway wouldn't it be 
 better they will equal both logically and literally?

stringof is a static debugging aid, just a string that kinda 
represents it in code. It isn't guaranteed to match anything, but 
should be enough that when you eyeball it it points you in the 
right direction... you shouldn't rely on it to be anything 
specific. typeid, on the other hand, is a published, documented 
object with methods and defined comparisons. So that's one 
difference.

The other one is indeed compile time vs runtime: stringof is 
purely compile time, whereas typeid() returns a runtime object on 
a runtime object. To see the difference, try:

Object o = new MyClass();
typeid(o);


You'll see it is MyClass, but the static versions (stringof, 
typeof, etC) will all think of it as Object.


 2) Where do these attributes come from? I mean `pure nothrow 
  nogc  safe` except ` property` that I set explicitly?

You didn't specify a return value for those functions, which 
meant the compiler inferred a bunch about it. It inferred the 
return value and those other attributes to fill in the gap.

If you gave an explicit return value ` property int` or 
` property void`, then it wouldn't automatically fill stuff in 
anymore.

drug <drug2004 bk.ru> writes:

05.10.2017 18:04, Adam D. Ruppe пишет:
 On Thursday, 5 October 2017 at 14:59:10 UTC, drug wrote:
 1) why .stringof and typeid() is equal logically and different in 
 fact? What is difference between them? Is it that stringof compile 
 time and typeid runtime things? Anyway wouldn't it be better they will 
 equal both logically and literally?

 
 stringof is a static debugging aid, just a string that kinda represents 
 it in code. It isn't guaranteed to match anything, but should be enough 
 that when you eyeball it it points you in the right direction... you 
 shouldn't rely on it to be anything specific. typeid, on the other hand, 
 is a published, documented object with methods and defined comparisons. 
 So that's one difference.
 
 The other one is indeed compile time vs runtime: stringof is purely 
 compile time, whereas typeid() returns a runtime object on a runtime 
 object. To see the difference, try:
 
 Object o = new MyClass();
 typeid(o);
 
 
 You'll see it is MyClass, but the static versions (stringof, typeof, 
 etC) will all think of it as Object.
 
 
 2) Where do these attributes come from? I mean `pure nothrow  nogc 
  safe` except ` property` that I set explicitly?

 
 You didn't specify a return value for those functions, which meant the 
 compiler inferred a bunch about it. It inferred the return value and 
 those other attributes to fill in the gap.
 
 If you gave an explicit return value ` property int` or ` property 
 void`, then it wouldn't automatically fill stuff in anymore.

Thank you, Adam!