Le 4 août 2012 00:50, "David Nadlinger" <see@klickverbot.at> a écrit :
>
> On Friday, 3 August 2012 at 22:23:23 UTC, Era Scarecrow wrote:
>>
>>  Seems like an ugly hack though (to get this done). Why not have another method of fullpathStringof or something similar? Then again if this is one of the few cases that could benefit from it, then maybe we should make it ugly so no one else will use it.
>
>
> This can't work in general. What should such a function return? The fully qualified name, i.e. including packages and modules? What is if the referred to entity is a nested function/local variable? What is if it is defined in a module which is not imported in the place where the string is mixed in?
>
> Regarding Philippe Sigaud's stuff: He has done a lot of great work, but exactly this use of strings is why some of his template constructions are not usable in the real world. Again, using .stringof in conjunction with string mixins is almost never a good idea.

FWIW, I agree with David that using .stringof is a last resort and can lead to nasty bugs. .stringof has a sometime incoherent behavior (I remember it showing the entire code inside a delegate literal)

But then, the code shown upstream do *not* use .stringof.

It uses __traits(parent, ) and __traits(qualifier, ), which are much more 'modern' and well-behaved.

For std.reflection that Andrei proposed 2 weeks ago, I feel the internal code will contain many __traits() calls. Nothing to be done about it. __traits is *the* way compile-time introspection is done in D.