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.

On Thursday, 29 September 2016 at 16:30:56 UTC, Eugene Wissner wrote:
>
> 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.

The point is that the fullyQualifiedName of something is not always enough to generate that type.
As you have seen in your usecase.

On 16.09.2016 01:10, Andrei Alexandrescu wrote:
> On 9/15/16 7:08 PM, Andrei Alexandrescu wrote:
>> Yes, that DIP. It would need some more formal work before defining an
>> implementation. Stefan, would you want to lead that effort? -- Andrei
>
> Actually I see Timon authored that (I thought it's an older DIP by
> Walter). Timon, would you want to finalize the definition so Stefan can
> write an implementation? Thx! -- Andrei

I have been wanting to do that for a long time. I'll try to find some time next week.

On 16.09.2016 01:25, Stefan Koch wrote:
> On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei Alexandrescu wrote:
>>
>> Yes, that DIP. It would need some more formal work before defining an
>> implementation. Stefan, would you want to lead that effort? -- Andrei
>
> I am not good at defining semantics, yet I would participate in a joint
> effort with Timon.
> ...

Sounds good.

> Be aware though that I am currently working at improving templates.
> And there might a significant win to be had.

On 09/29/2016 03:27 PM, Timon Gehr wrote:
> On 16.09.2016 01:10, Andrei Alexandrescu wrote:
>> On 9/15/16 7:08 PM, Andrei Alexandrescu wrote:
>>> Yes, that DIP. It would need some more formal work before defining an
>>> implementation. Stefan, would you want to lead that effort? -- Andrei
>>
>> Actually I see Timon authored that (I thought it's an older DIP by
>> Walter). Timon, would you want to finalize the definition so Stefan can
>> write an implementation? Thx! -- Andrei
>
> I have been wanting to do that for a long time. I'll try to find some
> time next week.

That would be awesome, thanks! -- Andrei

On 09/29/2016 07:02 PM, David Nadlinger wrote:
> On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner wrote:
>> Any chance to get this one working:
>>
>> import std.typecons;
>>
>> enum Stuff
>> {
>>     asdf,
>> }
>>
>> void main()
>> {
>>     BitFlags!Stuff a;
>>     mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
>> }
> 
> 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]

What are the issues with fullyQualifiedName in that context? I mean other than Voldemort types of course. I'd expect `static import` + `fullyQualifiedName` combo to be reasonably reliable and used it a lot in the past. Do you refer to aliases with changed protection attributes?

On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote:
> On 09/29/2016 07:02 PM, David Nadlinger wrote:
>> [...]
>
> What are the issues with fullyQualifiedName in that context? I mean other than Voldemort types of course. I'd expect `static import` + `fullyQualifiedName` combo to be reasonably reliable and used it a lot in the past. Do you refer to aliases with changed protection attributes?

The problem is the default template parameter Flag!"unsafe",
because fqn makes it into "cast(Flag)".
Getting this right is a bit tricky.

On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote:
> On Saturday, 1 October 2016 at 10:19:21 UTC, Dicebot wrote:
>> On 09/29/2016 07:02 PM, David Nadlinger wrote:
>>> [...]
>>
>> What are the issues with fullyQualifiedName in that context? I mean other than Voldemort types of course. I'd expect `static import` + `fullyQualifiedName` combo to be reasonably reliable and used it a lot in the past. Do you refer to aliases with changed protection attributes?
>
> The problem is the default template parameter Flag!"unsafe",
> because fqn makes it into "cast(Flag)".
> Getting this right is a bit tricky.

Isn't it a problem with library implementation though, one that would be easy to fix if FQN is to become a compiler built-in?

Reason why I'd like to have something akin to FQN for code generation is because it allow to generate (and save to file) non-templated methods directly importing required symbols (only generator function has to be templated). This can be of great importance if you consider classes and virtual methods.

On Saturday, 1 October 2016 at 19:54:13 UTC, Dicebot wrote:
> On Saturday, 1 October 2016 at 15:06:44 UTC, Stefan Koch wrote:
>> The problem is the default template parameter Flag!"unsafe",
>> because fqn makes it into "cast(Flag)".
>> Getting this right is a bit tricky.
>
> Isn't it a problem with library implementation though, one that would be easy to fix if FQN is to become a compiler built-in?

It is easier then doing it in a template for sure.
But it still requires a bit of AST-traversal.
And I fear differing from phobos could make it harder to get the PR merged.
since the __trait is supposed to be a drop-in replacement for the phobos template.