Re: Default Template Instantiation
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:
On Monday, 19 September 2016 at 22:17:34 UTC, Mathias Lang
wrote:
[...]
Good example, thanks for the information.
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.
}
If you want, take a look at dtemplate.d in the compiler source. :)
I would advise to do this when well rested and motivated.
Re: Default Template Instantiation
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:
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.
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.
}
Re: Default Template Instantiation
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.
Re: Default Template Instantiation
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
Re: Default Template Instantiation
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`.
Re: Default Template Instantiation
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.
Re: Default Template Instantiation
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)() {...}
Re: Default Template Instantiation
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.
Re: Default Template Instantiation
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.
Re: Default Template Instantiation
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?
Re: Default Template Instantiation
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.
