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

On Thursday, 15 September 2016 at 22:58:12 UTC, Stefan Koch wrote:
> The Performance-Penalty will be less then on templates.
Let me add a disclaimer, I _think_ the performance penalty _can_ be less then the penalty on templates.

Also static if can sometimes lead to counter-intuitive situations,
static foreach will likely be worse in that regard.

Implementation issues aside, and the DIP aside.
What would be the semantics you would want for this ?

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.

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

On Thursday, 15 September 2016 at 23:25:34 UTC, Stefan Koch wrote:
> On Thursday, 15 September 2016 at 23:08:54 UTC, Andrei Alexandrescu wrote:
>>
>> Yes, that DIP.[http://wiki.dlang.org/DIP57] 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.

I thought some more about this. static foreach is probably not a good idea at this point.

We should focus on getting the existing features to do their job properly and we won't have to add yet more meanings to the word static.

Our code-generation facilities with CTFE and mixins are very good indeed.
When polished CTFE can totally be used as a serious workhorse for cases that would have fallen intro the static foreach category.

On Friday, 16 September 2016 at 00:57:13 UTC, Stefan Koch wrote:
>
> When polished CTFE can totally be used as a serious workhorse for cases that would have fallen intro the static foreach category.

When you get your polished CTFE finished, you might consider a blog post on it (including an example with use cases for static foreach would be cool too).

On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:
> I am going to submit a PR soon.

https://github.com/dlang/dmd/pull/6134
Here it is.

On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch wrote:
> On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:
>
>> I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none.
>
> That was supposed to say : I would like to see [test cases from] users of fullyQulifiedName.

Any chance to get this one working:

import std.typecons;

enum Stuff
{
	asdf,
}

void main()
{
	BitFlags!Stuff a;
	mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
}

?

Btw __traits(fullyQualifiedName, typeof(a)) generates:
std.typecons.BitFlags!(Stuff, cast(Flag)false)

std.traits.fullyQualifiedName generates:
std.typecons.BitFlags!(fqn.Stuff, cast(Flag)false)


("fqn" is the name of the executable)

On Thursday, 29 September 2016 at 13:58:44 UTC, Eugene Wissner wrote:
> On Wednesday, 14 September 2016 at 20:28:13 UTC, Stefan Koch wrote:
>> On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:
>>
>>> I would like to see users of fullyQualifiedName because apart from binderoo code which seems to work, I have none.
>>
>> That was supposed to say : I would like to see [test cases from] users of fullyQulifiedName.
>
> Any chance to get this one working:
>
> import std.typecons;
>
> enum Stuff
> {
> 	asdf,
> }
>
> void main()
> {
> 	BitFlags!Stuff a;
> 	mixin(__traits(fullyQualifiedName, typeof(a)) ~ " c;");
> }
>
> ?
>
> Btw __traits(fullyQualifiedName, typeof(a)) generates:
> std.typecons.BitFlags!(Stuff, cast(Flag)false)
>
> std.traits.fullyQualifiedName generates:
> std.typecons.BitFlags!(fqn.Stuff, cast(Flag)false)
>
>
> ("fqn" is the name of the executable)

The reason why this fails is because of the cast(Flag) which should be cast(Flag!"unsafe").
I can probably make it work tough,
that means more special casing :)

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]

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

On Thursday, 29 September 2016 at 14:49:03 UTC, Stefan Koch wrote:
> The reason why this fails is because of the cast(Flag) which should be cast(Flag!"unsafe").
> I can probably make it work tough,
> that means more special casing :)

Yes, I know. See this topic for the first discussion:
http://forum.dlang.org/post/igsxmowtguwvngnqullx@forum.dlang.org

It would be really great :)