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?

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.

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?

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.

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.

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)() {...}

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.

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`.

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

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.