On Thursday, 29 September 2016 at 16:02:53 UTC, David Nadlinger
wrote:
This wouldn't be a correct use of the feature anyway, since it
runs into all sorts of fundamental issues with imports/scoping,
aliases and templates. Using .stringof/fullyQualifiedName to
generate a reference to a type or symbol in a string mixin is a
mistake, period. Unfortunately, the misconception that they
*are* code generation tools is fairly wide-spread, to the point
where dlang.org contains a similarly misleading comment. [1]
Just emit the typeof expression into the mixin string, e.g.
`mixin("typeof(a) c;");`. It should be fairly easy to convince
yourself that a similar rewrite is always possible, even if it
is sometimes less obvious (in some situations, you might need
to change some code to, say, pass on a template parameter `T`
all the way to the point of the mixin() call instead of
`T.stringof`).
— David
[1] https://github.com/dlang/dlang.org/pull/380
Maybe it is correct about the usage of
.stringof/fullyQualifiedName. But I still don't understand the
argumentation. Why it is so bad if something works as expected,
why it is so evil if fullyQualifiedName would return what is
says: the fully qualified name.
The problem is you can never know all the use cases of some
feature. It is just pointless to try to predict where a user will
need a feature. I had a use case where I could be sure that
everything needed is imported and where I could save compile time
and make the function signatures a bit simpler.
Let us just remove fullyQualifiedName from the language. Why
spend effort with it? Why should one write into the
documentation: Oh, you thought it would work? How funny! This
function is just for fun of the library creators and is only good
to pass it to writeln(), it isn't supposed to work.
