www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Default Template Instantiation

reply Jonathan Marler <johnnymarler gmail.com> writes:
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
parent reply Basile B. <b2.temp gmx.com> writes:
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
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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:
 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.
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?
Sep 19 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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:
 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.
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.
Sep 19 2016
parent reply Stefan Koch <uplink.coder googlemail.com> writes:
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
parent reply Jonathan Marler <johnnymarler gmail.com> writes:
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:
 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)() {...}
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.
Sep 19 2016
parent reply Mathias Lang via Digitalmars-d <digitalmars-d puremagic.com> writes:
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:

 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)() {...}
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.
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
next sibling parent Stefan Koch <uplink.coder googlemail.com> writes:
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
prev sibling parent Jonathan Marler <johnnymarler gmail.com> writes:
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>:

[...]
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`.
Good example, thanks for the information.
Sep 19 2016