www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The worst Phobos template (in binderoo)

reply Stefan Koch <uplink.coder googlemail.com> writes:
Hi Guys,

I recently had a closer look at the templates that cost the most 
time to instantiate in the frontend.

and there is one clear winner.

FullyQualified name from std.traits.
It takes a whooping 500 milliseconds(on my test-case) for it's 
semantic phase.
this is because this template is recursive and because it 
instantiates std.format.format which is on fourth place for slow 
templates.

The functionality can be implemented with a __trait and that 
implementation would be 500 times faster.

I am going to submit a PR soon.

However I cannot guarantee that the newly introduces trait work 
the same in all cases.
As templates can behave surprisingly sometimes.

I would like to see users of fullyQualifiedName because apart 
from binderoo code which seems to work, I have none.
Sep 14 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 14 2016
next sibling parent Atila Neves <atila.neves gmail.com> writes:
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.


I use it in unit_threaded, which now explains why the 
compile-time reflection is a bit slow. I need to figure out how 
to measure it though.

Atila
Sep 14 2016
prev sibling next sibling parent reply Dicebot <public dicebot.lv> writes:
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.


I wrote a type overload of it long time ago to be used in vibe.d 
REST interface generator - combined with static imports it 
ensured symbol hygienne. Though it possible current 
implementation doesn't use it anymore.

Intended semantics was to be as close to this as possible:

mixin("alias T2 = " ~ fqn!T);
static assert(is(T2 == T));

In that sense builtin trait could be a better option.
Sep 14 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 06:08:33 UTC, Dicebot wrote:

 mixin("alias T2 = " ~ fqn!T);
 static assert(is(T2 == T));

 In that sense builtin trait could be a better option.


Yes a builtin trait is the better option.
I made a youtube video about that.
Showing you how bad FullyQualifiedName is and how much better a 
trait is.
https://www.youtube.com/watch?v=l1Ph3Nn0en0
Sep 15 2016
prev sibling parent reply Eugene Wissner <belka caraus.de> writes:
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)
Sep 29 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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 :)
Sep 29 2016
parent Eugene Wissner <belka caraus.de> writes:
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 :)
Sep 29 2016
prev sibling parent reply David Nadlinger <code klickverbot.at> writes:
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
Sep 29 2016
next sibling parent reply Eugene Wissner <belka caraus.de> writes:
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.
Sep 29 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 29 2016
prev sibling parent reply Dicebot <public dicebot.lv> writes:
 protected-headers="v1"
From: Dicebot <public dicebot.lv>
Newsgroups: d,i,g,i,t,a,l,m,a,r,s,.,D
Subject: Re: The worst Phobos template (in binderoo)
References: <zvdyrdugngjvycyjecge forum.dlang.org>
 <sgeqmrrhdauzjpkohdfk forum.dlang.org> <wvohffzylpgsspersigv forum.dlang.org>
 <kcpnmirogoftydbvtboo forum.dlang.org>
In-Reply-To: <kcpnmirogoftydbvtboo forum.dlang.org>

--eeUcpHijaAE62pVqgbHaQ5ATLR3pK8HSR
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable

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;");
 }


=20
 This wouldn't be a correct use of the feature anyway, since it runs int=


o

 all sorts of fundamental issues with imports/scoping, aliases and
 templates. Using .stringof/fullyQualifiedName to generate a reference t=


o

 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?


--eeUcpHijaAE62pVqgbHaQ5ATLR3pK8HSR--
Oct 01 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Oct 01 2016
parent reply Dicebot <public dicebot.lv> writes:
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.
Oct 01 2016
parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Oct 01 2016
prev sibling next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch 
wrote:

 It takes a whooping 500 milliseconds


Ahm... I misread my performance graph
it's 138ms for the first instanciation.
and around 5ms for every following one.
the total time spent on it was 500ms
Sep 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/14/2016 04:52 PM, Stefan Koch wrote:

 On Wednesday, 14 September 2016 at 20:24:13 UTC, Stefan Koch wrote:

 It takes a whooping 500 milliseconds


 Ahm... I misread my performance graph
 it's 138ms for the first instanciation.
 and around 5ms for every following one.
 the total time spent on it was 500ms


(Disclaimer: I didn't run any speed tests.) By looking at the definition 
of fullyQualifiedName it seems to me we can go a long way with 
traditional optimization techniques. For example consider:

string result = join(
   map!(a => format("%s%s", a[0], a[1]))(
     zip([staticMap!(storageClassesString, parameterStC)],
       [staticMap!(fullyQualifiedName, parameters)])),

This is neat, and it's neat squared because it works during compilation, 
but at some point if the resulting code runs slowly, there's no shame in 
applying old school optimization. Instead of join/map a simple loop 
should suffice; no need to use format with "%s%s" over simple 
concatenation; array zipping may be done with simple loops too.

Same a few lines below - just replace return format("%s%s%s%s%s%s%s%s", 
...) with simple concatenation. Same goes with format("shared(%s)", 
...), format("%s(%s)", ...) etc. In casual runtime code such code is 
totally fine, but in library code we'd do good to eliminate the use of 
format (which is a mini-interpreter) if speed considerations tell us to.

The unittests seem excessive too. Yes, there is such a thing as too much 
of a good thing. And use a lot of format during compilation as well :o). 
In unittests, a bunch of static asserts may be replaced with regular 
asserts.


Andrei
Sep 14 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei 
Alexandrescu wrote:

 On 09/14/2016 04:52 PM, Stefan Koch wrote:

 [...]


 (Disclaimer: I didn't run any speed tests.) By looking at the 
 definition of fullyQualifiedName it seems to me we can go a 
 long way with traditional optimization techniques. For example 
 consider:

 [...]


staticMap is number 3 in the top-slow-templates list.
And the code inside it really does not matter so much.
What matters is recursive instanciation.

the evaluation of the function is fast in comparison to the time 
the template-subsystem takes.

I believe this cannot be fixed by changing a library solution.
Sep 14 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/14/2016 05:50 PM, Stefan Koch wrote:

 On Wednesday, 14 September 2016 at 21:06:10 UTC, Andrei Alexandrescu wrote:

 On 09/14/2016 04:52 PM, Stefan Koch wrote:

 [...]


 (Disclaimer: I didn't run any speed tests.) By looking at the
 definition of fullyQualifiedName it seems to me we can go a long way
 with traditional optimization techniques. For example consider:

 [...]


 staticMap is number 3 in the top-slow-templates list.
 And the code inside it really does not matter so much.
 What matters is recursive instanciation.

 the evaluation of the function is fast in comparison to the time the
 template-subsystem takes.

 I believe this cannot be fixed by changing a library solution.


Apparently we need that static foreach iteration. -- Andrei
Sep 15 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei 
Alexandrescu wrote:

 Apparently we need that static foreach iteration. -- Andrei


What exactly do you mean ?
As long as we instanciate n templates for a member nested n 
levels the overhead is massive!
How would static foreach help ?
Sep 15 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/15/2016 08:35 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu wrote:

 Apparently we need that static foreach iteration. -- Andrei


 What exactly do you mean ?
 As long as we instanciate n templates for a member nested n levels the
 overhead is massive!
 How would static foreach help ?


I thought staticMap is just a (simulated) loop that applies the same 
template in sequence. -- Andrei
Sep 15 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei 
Alexandrescu wrote:

 On 09/15/2016 08:35 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei 
 Alexandrescu wrote:

 Apparently we need that static foreach iteration. -- Andrei


 What exactly do you mean ?
 As long as we instanciate n templates for a member nested n 
 levels the
 overhead is massive!
 How would static foreach help ?


 I thought staticMap is just a (simulated) loop that applies the 
 same template in sequence. -- Andrei


staticMap is a recursive variadic template.
CompileTime wise the worst class a template can be in.
it expands to a series of templates instancing itself log(n) 
times.
causing 2n*log(n) instances in total.

It's not a pretty picture.
Sep 15 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/15/2016 09:27 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei Alexandrescu wrote:

 On 09/15/2016 08:35 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei Alexandrescu
 wrote:

 Apparently we need that static foreach iteration. -- Andrei


 What exactly do you mean ?
 As long as we instanciate n templates for a member nested n levels the
 overhead is massive!
 How would static foreach help ?


 I thought staticMap is just a (simulated) loop that applies the same
 template in sequence. -- Andrei


 staticMap is a recursive variadic template.


Can recursion be replaced with iteration? Assume you have static foreach 
at your disposal. -- Andrei
Sep 15 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 13:49:46 UTC, Andrei 
Alexandrescu wrote:

 On 09/15/2016 09:27 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 13:20:16 UTC, Andrei 
 Alexandrescu wrote:

 On 09/15/2016 08:35 AM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 12:26:08 UTC, Andrei 
 Alexandrescu
 wrote:

 Apparently we need that static foreach iteration. -- Andrei


 What exactly do you mean ?
 As long as we instanciate n templates for a member nested n 
 levels the
 overhead is massive!
 How would static foreach help ?


 I thought staticMap is just a (simulated) loop that applies 
 the same
 template in sequence. -- Andrei


 staticMap is a recursive variadic template.


 Can recursion be replaced with iteration? Assume you have 
 static foreach at your disposal. -- Andrei


You tell me, you are the expert on templates :o)
I cannot be certain but I think, It would probably work.

static foreach on the other hand is a whole new can of worms.
As walter will be able to tell you.
Sep 15 2016
parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 09/15/2016 10:08 AM, Stefan Koch wrote:

 static foreach on the other hand is a whole new can of worms.
 As walter will be able to tell you.


It's time to open it. -- Andrei
Sep 15 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei 
Alexandrescu wrote:

 On 09/15/2016 10:08 AM, Stefan Koch wrote:

 static foreach on the other hand is a whole new can of worms.
 As walter will be able to tell you.


 It's time to open it. -- Andrei


Please give me an example on how it should work.
Sep 15 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei 
 Alexandrescu wrote:

 On 09/15/2016 10:08 AM, Stefan Koch wrote:

 static foreach on the other hand is a whole new can of worms.
 As walter will be able to tell you.


 It's time to open it. -- Andrei


 Please give me an example on how it should work.


Are we talking about http://wiki.dlang.org/DIP57 ?

I think I can give you a partial solution for that.
The Performance-Penalty will be less then on templates.

However I can smell a bunch of un-intuitive corner-cases hiding 
in there.
Sep 15 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 9/15/16 6:58 PM, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 14:43:16 UTC, Stefan Koch wrote:

 On Thursday, 15 September 2016 at 14:38:41 UTC, Andrei Alexandrescu
 wrote:

 On 09/15/2016 10:08 AM, Stefan Koch wrote:

 static foreach on the other hand is a whole new can of worms.
 As walter will be able to tell you.


 It's time to open it. -- Andrei


 Please give me an example on how it should work.


 Are we talking about http://wiki.dlang.org/DIP57 ?

 I think I can give you a partial solution for that.
 The Performance-Penalty will be less then on templates.

 However I can smell a bunch of un-intuitive corner-cases hiding in there.


Yes, that DIP. It would need some more formal work before defining an 
implementation. Stefan, would you want to lead that effort? -- Andrei
Sep 15 2016
next sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 15 2016
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 29 2016
parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
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
Sep 29 2016
prev sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 15 2016
next sibling parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 15 2016
parent jmh530 <john.michael.hall gmail.com> writes:
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).
Sep 16 2016
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
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.
Sep 29 2016
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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 ?
Sep 15 2016
prev sibling next sibling parent reply Pierre Krafft <kpierre+dlang outlook.com> writes:
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.


I've had to use fullyQualifiedName in some string mixins. Take a 
look at 
https://github.com/BlackEdder/painlessjson/blob/9f9b94b3a47ada4ffdea16ef5dc5476c74cb9a06/source/painlessjson/
ainlessjson.d#L415. I also recommend using GitHub search to find other examples.
Sep 14 2016
parent David Nadlinger <code klickverbot.at> writes:
On Wednesday, 14 September 2016 at 22:48:29 UTC, Pierre Krafft 
wrote:

 I've had to use fullyQualifiedName in some string mixins.


Unless there is more to the example than what meets the eye, "had 
to" isn't quite true, and even with the `import moduleName!…` 
hack, your code is still unnecessarily restrictive. Just use ` ~ 
"fromJSON!(typeof(t." ~ name ~ "))…"` instead.

I'd really like to know where the notion that stringifying 
symbols for mixin code generation is a viable choice comes from. 
People seem to try with an irritating regularity, only to 
inevitably discover that it doesn't actually work some time 
later. That one can get dangerously close now that we have 
`moduleName` doesn't exactly help either.

  — David
Sep 14 2016
prev sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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.
Sep 16 2016