digitalmars.D - Default Template Instantiation
- Jonathan Marler (19/19) Sep 19 2016 If you have a template where:
- Basile B. (17/37) Sep 19 2016 My understanding of this case is that the usage of the eponymous
- Jonathan Marler (5/47) Sep 19 2016 Yes that's why the template cannot deduce the parameters. The
- Stefan Koch (6/10) Sep 19 2016 This would be a destabilizing language-change and require even
- Jonathan Marler (12/21) Sep 19 2016 That's what I was wondering. I was trying to think of examples
- Stefan Koch (4/9) Sep 19 2016 Consider void functionOrTemplate() {...} and
- Jonathan Marler (7/17) Sep 19 2016 Oh you're right, I didn't think that templates could share the
- Mathias Lang via Digitalmars-d (14/33) Sep 19 2016 No you can't. The example is wrong, but Stefan is right.
- Stefan Koch (5/6) Sep 19 2016 Try it.
- Jonathan Marler (2/18) Sep 19 2016 Good example, thanks for the information.
- Heromyth (24/50) May 17 2018 Maybe the compiler can do more works to make the code more
- Stefan Koch (3/32) May 17 2018 If you want, take a look at dtemplate.d in the compiler source. :)
If you have a template where:
1) All parameters are optional
2) The parameters cannot be deduced
Would it be reasonable to instantiate the template with the
default parameter values? For example:
template Foo(string str = "some string", T...)
{
class Foo
{
// class implementation
this() { }
}
}
auto foo = new Foo!()(); // OK
auto foo = new Foo(); // Error: cannot deduce template parameters
In this example, there's no way to deduce the template parameters
for Foo, however, since they are not specified, would it be
reasonable to just use the defaults? str would be "some string"
and T would be empty?
Sep 19 2016
On Monday, 19 September 2016 at 19:38:37 UTC, Jonathan Marler
wrote:
If you have a template where:
1) All parameters are optional
2) The parameters cannot be deduced
Would it be reasonable to instantiate the template with the
default parameter values? For example:
template Foo(string str = "some string", T...)
{
class Foo
{
// class implementation
this() { }
}
}
auto foo = new Foo!()(); // OK
auto foo = new Foo(); // Error: cannot deduce template
parameters
In this example, there's no way to deduce the template
parameters for Foo, however, since they are not specified,
would it be reasonable to just use the defaults? str would be
"some string" and T would be empty?
My understanding of this case is that the usage of the eponymous
member must include all the template parameters because for
example we could have:
template Foo(string str = "some string", T...)
{
class Foo
{
T[0] a;
T[1] b;
// class implementation
this() { }
}
}
The way "new Foo" is used must tells what are the parent template
parameters.
Sep 19 2016
On Monday, 19 September 2016 at 19:53:27 UTC, Basile B. wrote:On Monday, 19 September 2016 at 19:38:37 UTC, Jonathan Marler wrote:Yes that's why the template cannot deduce the parameters. The question is, when the parameters cannot be deduced, and they are all optional, would it be reasonable for the compiler to infer that the user intended to use the default parameters?If you have a template where: 1) All parameters are optional 2) The parameters cannot be deduced Would it be reasonable to instantiate the template with the default parameter values? For example: template Foo(string str = "some string", T...) { class Foo { // class implementation this() { } } } auto foo = new Foo!()(); // OK auto foo = new Foo(); // Error: cannot deduce template parameters In this example, there's no way to deduce the template parameters for Foo, however, since they are not specified, would it be reasonable to just use the defaults? str would be "some string" and T would be empty?My understanding of this case is that the usage of the eponymous member must include all the template parameters because for example we could have: template Foo(string str = "some string", T...) { class Foo { T[0] a; T[1] b; // class implementation this() { } } } The way "new Foo" is used must tells what are the parent template parameters.
Sep 19 2016
On Monday, 19 September 2016 at 20:21:30 UTC, Jonathan Marler wrote:Yes that's why the template cannot deduce the parameters. The question is, when the parameters cannot be deduced, and they are all optional, would it be reasonable for the compiler to infer that the user intended to use the default parameters?This would be a destabilizing language-change and require even more logic for templates. I don't mind saying that any further complication of template overload resolution is a rather unpleasant for me to think about.
Sep 19 2016
On Monday, 19 September 2016 at 20:47:00 UTC, Stefan Koch wrote:On Monday, 19 September 2016 at 20:21:30 UTC, Jonathan Marler wrote:That's what I was wondering. I was trying to think of examples that this kind of feature would over-complicate. I've been thinking about it the last few days and I have the same reservations about making template deduction more complicated than it already is. That being said, I have thought of some examples that this feature would make much nicer. I don't know if I would call this a "destabalizing" language change though. It should be backwards compatible with the existing semantics. It adds an extra step to type deduction, but this would be the very last step of type deduction so it would not override any existing semantics.Yes that's why the template cannot deduce the parameters. The question is, when the parameters cannot be deduced, and they are all optional, would it be reasonable for the compiler to infer that the user intended to use the default parameters?This would be a destabilizing language-change and require even more logic for templates.
Sep 19 2016
On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler wrote:I don't know if I would call this a "destabalizing" language change though. It should be backwards compatible with the existing semantics. It adds an extra step to type deduction, but this would be the very last step of type deduction so it would not override any existing semantics.Consider void functionOrTemplate() {...} and functionOrTemplate(uint N = 1)() {...}
Sep 19 2016
On Monday, 19 September 2016 at 21:14:38 UTC, Stefan Koch wrote:On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler wrote:Oh you're right, I didn't think that templates could share the same name as functions. You can't do this with classes: class classOrTemplate { } class classOrTemplate(uint N=1) { } With this new information, yes this would be a "destabalizing" language change. Thanks for the example. I'm against this.I don't know if I would call this a "destabalizing" language change though. It should be backwards compatible with the existing semantics. It adds an extra step to type deduction, but this would be the very last step of type deduction so it would not override any existing semantics.Consider void functionOrTemplate() {...} and functionOrTemplate(uint N = 1)() {...}
Sep 19 2016
2016-09-19 23:18 GMT+02:00 Jonathan Marler via Digitalmars-d < digitalmars-d puremagic.com>:On Monday, 19 September 2016 at 21:14:38 UTC, Stefan Koch wrote:No you can't. The example is wrong, but Stefan is right. Consider: ``` template Foo (T = string) { } template TakesAlias(alias Sym) {} alias TakesAlias!(Foo) Bar; ``` In this context, is `TakesAlias` instantiated with the template or the template instantiation ? It is essentially the same category of problems as when trying to use a parameterless-functions, sometime you end up calling it because of the optional parenthesis. Except that for functions we can use `&` or `typeof`.On Monday, 19 September 2016 at 21:09:37 UTC, Jonathan Marler wrote:Oh you're right, I didn't think that templates could share the same name as functions. You can't do this with classes: class classOrTemplate { } class classOrTemplate(uint N=1) { } With this new information, yes this would be a "destabalizing" language change. Thanks for the example. I'm against this.I don't know if I would call this a "destabalizing" language change though. It should be backwards compatible with the existing semantics. It adds an extra step to type deduction, but this would be the very last step of type deduction so it would not override any existing semantics.Consider void functionOrTemplate() {...} and functionOrTemplate(uint N = 1)() {...}
Sep 19 2016
Stefan Koch <uplink.coder googlemail.com> On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:No you can't. The example is wrong, but Stefan is right.Try it. It got fixed a few versions ago. Maybe it's broken again ? I remember it working with 2.068
Sep 19 2016
On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:2016-09-19 23:18 GMT+02:00 Jonathan Marler via Digitalmars-d < digitalmars-d puremagic.com>:Good example, thanks for the information.[...]No you can't. The example is wrong, but Stefan is right. Consider: ``` template Foo (T = string) { } template TakesAlias(alias Sym) {} alias TakesAlias!(Foo) Bar; ``` In this context, is `TakesAlias` instantiated with the template or the template instantiation ? It is essentially the same category of problems as when trying to use a parameterless-functions, sometime you end up calling it because of the optional parenthesis. Except that for functions we can use `&` or `typeof`.
Sep 19 2016
On Monday, 19 September 2016 at 22:59:53 UTC, Jonathan Marler wrote:On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:Maybe the compiler can do more works to make the code more readable. Here are my examples: template EventHandler(T=Object) { alias EventHandler = void delegate(T sender); } void test01(EventHandler handler) // Error { // It's what I want. However, it doesn't work. } void test02(EventHandler!() handler) { // It works. Howerve, it ... } void test03()(EventHandler handler) { // It works too. Howerve, it ... } void test04(EventHandler!string handler) { // It's OK. }2016-09-19 23:18 GMT+02:00 Jonathan Marler via Digitalmars-d < digitalmars-d puremagic.com>:Good example, thanks for the information.[...]No you can't. The example is wrong, but Stefan is right. Consider: ``` template Foo (T = string) { } template TakesAlias(alias Sym) {} alias TakesAlias!(Foo) Bar; ``` In this context, is `TakesAlias` instantiated with the template or the template instantiation ? It is essentially the same category of problems as when trying to use a parameterless-functions, sometime you end up calling it because of the optional parenthesis. Except that for functions we can use `&` or `typeof`.
May 17 2018
On Thursday, 17 May 2018 at 08:37:01 UTC, Heromyth wrote:On Monday, 19 September 2016 at 22:59:53 UTC, Jonathan Marler wrote:If you want, take a look at dtemplate.d in the compiler source. :) I would advise to do this when well rested and motivated.On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang wrote:Maybe the compiler can do more works to make the code more readable. Here are my examples: template EventHandler(T=Object) { alias EventHandler = void delegate(T sender); } void test01(EventHandler handler) // Error { // It's what I want. However, it doesn't work. } void test02(EventHandler!() handler) { // It works. Howerve, it ... } void test03()(EventHandler handler) { // It works too. Howerve, it ... } void test04(EventHandler!string handler) { // It's OK. }[...]Good example, thanks for the information.
May 17 2018