https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #30 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-03-03 17:56:27 EET ---
The irony is that as much as I dislike this approach, it does allow doing more things with template alias parameters, and I've started to rely on it in my own code. I even took it a step further in https://github.com/D-Programming-Language/dmd/pull/3345 to do the same things with methods.

I noticed Kenji wrote this on the D Wiki: http://wiki.dlang.org/Brush_Up_Language_Features#Nested_Symbols

The idea is to introduce "static alias" template parameters, which make it explicit if the alias parameter needs to transmit the symbol's context to the template (and thus nest the template within that context), or not. I think it is a sensible approach in lieu of automagically determining if that context is needed by the template (which Kenji claims is "mostly impossible").

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #31 from Dicebot <public@dicebot.lv> 2014-03-03 08:08:42 PST ---
(In reply to comment #30)
> The irony is that as much as I dislike this approach, it does allow doing more things with template alias parameters, and I've started to rely on it in my own code. I even took it a step further in

It does not really matter. What is the point of adding more features is they break basic guarantees? It does not fit nicely with idea that templates are not affected by instantiation scope and forces you to pollute your code with loads of boilerplate just to be sure.

I am effectively forced to go though my code upon next release and replace all

void foo(alias X)(...) {}

with

template foo(alias X)
{
    static void foo(...) {]
}

_everywhere_. How I am even supposed to not hate it?

> The idea is to introduce "static alias" template parameters, which make it explicit if the alias parameter needs to transmit the symbol's context to the template (and thus nest the template within that context), or not. I think it is a sensible approach in lieu of automagically determining if that context is needed by the template (which Kenji claims is "mostly impossible").

It should be other way around, "dynamic alias" for those who do want a context pointer. "Don't pay for what you don't use" and principle of least surprise.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #32 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-03-03 18:12:41 EET ---
(In reply to comment #31)
> It does not really matter. What is the point of adding more features is they break basic guarantees? It does not fit nicely with idea that templates are not affected by instantiation scope and forces you to pollute your code with loads of boilerplate just to be sure.

I certainly won't complain if this change is reverted and replaced with a suitable alternative, even if it means I'll have to rewrite all the code that depends on it.

> It should be other way around, "dynamic alias" for those who do want a context pointer. "Don't pay for what you don't use" and principle of least surprise.

Fair enough, though we don't have a "dynamic" keyword we can abuse here...

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #33 from Kenji Hara <k.hara.pg@gmail.com> 2014-03-03 08:16:49 PST ---
(In reply to comment #30)
> I noticed Kenji wrote this on the D Wiki: http://wiki.dlang.org/Brush_Up_Language_Features#Nested_Symbols
> 
> The idea is to introduce "static alias" template parameters, which make it explicit if the alias parameter needs to transmit the symbol's context to the template (and thus nest the template within that context), or not. I think it is a sensible approach in lieu of automagically determining if that context is needed by the template (which Kenji claims is "mostly impossible").

In my thought, excepting lambdas, the context-inference feature is not implementable, because it will make the mangling names of the function local symbols unstable. (On lambdas, they have unique names in their declared scope, so we can stop encoding their 'this' pointer into the mangled name.) So if we really need to capture any symbols without their contexts, the idea "static alias parameter" would be the most better solution.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #34 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-03-03 18:18:37 EET ---
(In reply to comment #33)
> because it will make the mangling names of the function local symbols unstable.

Could you please explain this further? Isn't name mangling only done once all semantics are resolved, so it will happen once the compiler knows if the template needs the context or not?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #35 from Kenji Hara <k.hara.pg@gmail.com> 2014-03-03 08:26:28 PST ---
(In reply to comment #34)
> (In reply to comment #33)
> > because it will make the mangling names of the function local symbols unstable.
> 
> Could you please explain this further? Isn't name mangling only done once all semantics are resolved, so it will happen once the compiler knows if the template needs the context or not?

Read the section "Do not mangle context-ness of parent lambdas" in http://wiki.dlang.org/Brush_Up_Language_Features

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #36 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-03-03 18:50:14 EET ---
(In reply to comment #35)
> Read the section "Do not mangle context-ness of parent lambdas" in http://wiki.dlang.org/Brush_Up_Language_Features

Thanks. Sorry I missed that.

So do you think that if we solve the lambda mangling problem, it would be possible to infer static-ness of alias parameters, thus avoiding the need of "static alias"?

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #37 from Kenji Hara <k.hara.pg@gmail.com> 2014-03-03 22:45:48 PST ---
(In reply to comment #36)
> (In reply to comment #35)
> So do you think that if we solve the lambda mangling problem, it would be
> possible to infer static-ness of alias parameters, thus avoiding the need of
> "static alias"?

My opinion is that would be impossible to infer static-ness in generic case. We can avoid the issue about lambdas by adding a hack for the mangling scheme, but the hack won't work for non-lambda functions.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------

https://d.puremagic.com/issues/show_bug.cgi?id=11946



--- Comment #38 from Vladimir Panteleev <thecybershadow@gmail.com> 2014-03-04 10:27:47 EET ---
Well, IMHO mangleof should just result in a forward reference error in such cases. As far as I can see, static inference is much more important than mangleof of nested functions inside those functions.

-- 
Configure issuemail: https://d.puremagic.com/issues/userprefs.cgi?tab=email
------- You are receiving this mail because: -------