On 24 July 2014 21:30, Manu <turkeyman@gmail.com> wrote:

> On 24 July 2014 21:25, Manu <turkeyman@gmail.com> wrote:
>
>> On 24 July 2014 19:37, John Colvin via Digitalmars-d < digitalmars-d@puremagic.com> wrote:
>>
>>> On Thursday, 24 July 2014 at 04:53:41 UTC, Manu via Digitalmars-d wrote:
>>>
>>>> I'm running into consistent problems with default args and argument
>>>> deduction in templates.
>>>> There seem to be 2 consistent classes of problem:
>>>>
>>>> struct S(size_t len = 10)
>>>> {
>>>>   ubyte[len] data;
>>>> }
>>>>
>>>> S!100 x; // this works fine
>>>> S y; // this doesn't work (!)
>>>> S!() z; // this works
>>>>
>>>> The template arg has a default arg, why require !() ??
>>>> This causes problems in meta code, where you want to create an instance
>>>> of
>>>> some T, and T may be a normal type with no template args, in which case
>>>> !()
>>>> is invalid, but a template type with default args should also be
>>>> acceptable, but it doesn't work because the meta code doesn't specify
>>>> !().
>>>>
>>>
>>> This opens a whole can of worms. It's very useful to be able to distinguish between templates and their instantiations. Seeing as D's alias system works on a pass-by-name system, you can't have a system where simply referring to a template instantiates it with no arguments.
>>>
>>> Apart from anything else it would break *so* much code.
>>>
>>
>> Isn't the call to the constructor enough to distinguish it is an instantiation rather than a reference to the template itself?
>>
>> S is a template
>> S!() is a type
>> S(x,y,z) is a call to it's constructor, the expression has a type
>>
>>  What is the useful distinction between S!()(x,y,z) and S(x,y,z)? How
>> does either one of them make referring to the template 'S' difficult?
>> Is there some conflicting syntax where the parentheses mean something
>> else when S perceived as a template? Why isn't the same problem applicable
>> to function templates?
>>
>
> Ack! Sorry! I misread, your response as being related to the constructor case, not the default arg case >_<
>
> I see the problem with the default arg case. It's a real shame, because it
> has rather annoying side effects in generic code, and it doesn't appear to
> follow the same logical rules as with functions.
> This is precisely the sort of thing Scott Myers would be unhappy about...
> Someone will need to 'explain' this for years to come, I don't think it's
> intuitive ;)
>

Although... the more I think about it, the more I wonder why it matters if
the syntax is ambiguous when the name is taken in isolation, that never
actually happens...
Why can't it just mean 'either the template, or the default arg
instantiation', and be resolved when it's actually used?
Is it possible for templates or types to both appear in the same context
and create an actual ambiguity? What would that expression look like?
The only place I can imagine a conflict could occur would be within an is()
expression, but I'm not sure... can a uninstantiated template be used in an
is() expression where a type would also be a meaningful fit?

Generally, templates do this:
  T!()
And types do this:
  T var;

It's clear syntactically from 'T!()' that T is not a default args
instantiation of T, because it's involved in a template instantiation
expression.
It's also clear from 'T var' that T is not a template, because a variable
needs to have a type.

On Thursday, 24 July 2014 at 06:17:26 UTC, Manu via Digitalmars-d
wrote:
> On 24 July 2014 16:02, anonymous via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Thursday, 24 July 2014 at 04:53:41 UTC, Manu via Digitalmars-d
>> wrote:
[...]
>>>  This causes problems in meta code, where you want to create an instance of
>>> some T, and T may be a normal type with no template args, in which case
>>> !()
>>> is invalid, but a template type with default args should also be
>>> acceptable, but it doesn't work because the meta code doesn't specify !().
>>>
>>
>> Add !() at the instantiation site.
>
>
> Then the code is broken for any type that isn't a template... it's a
> mutually exclusive situation.

I mean, don't accept both types and templates. Demand types in
the meta code, and do the instantiation of S when instantiating
the meta code: metaCode!(S!()).

I understand that it's a bit ugly, but I don't see the bigger
issue here. Do you have an example where there's more to it than
just having to add !() somewhere?

I do see the problem with the other case, S(T) {this(T) {...}},
though. You can't just do metaCode!(S!()) there.

On Thursday, 24 July 2014 at 11:25:28 UTC, Manu via Digitalmars-d wrote:
> On 24 July 2014 19:37, John Colvin via Digitalmars-d <
> digitalmars-d@puremagic.com> wrote:
>
>> On Thursday, 24 July 2014 at 04:53:41 UTC, Manu via Digitalmars-d wrote:
>>
>>> I'm running into consistent problems with default args and argument
>>> deduction in templates.
>>> There seem to be 2 consistent classes of problem:
>>>
>>> struct S(size_t len = 10)
>>> {
>>>   ubyte[len] data;
>>> }
>>>
>>> S!100 x; // this works fine
>>> S y; // this doesn't work (!)
>>> S!() z; // this works
>>>
>>> The template arg has a default arg, why require !() ??
>>> This causes problems in meta code, where you want to create an instance of
>>> some T, and T may be a normal type with no template args, in which case
>>> !()
>>> is invalid, but a template type with default args should also be
>>> acceptable, but it doesn't work because the meta code doesn't specify !().
>>>
>>
>> This opens a whole can of worms. It's very useful to be able to
>> distinguish between templates and their instantiations. Seeing as D's alias
>> system works on a pass-by-name system, you can't have a system where simply
>> referring to a template instantiates it with no arguments.
>>
>> Apart from anything else it would break *so* much code.
>>
>
> Isn't the call to the constructor enough to distinguish it is an
> instantiation rather than a reference to the template itself?
>
> S is a template
> S!() is a type
> S(x,y,z) is a call to it's constructor, the expression has a type
>
> What is the useful distinction between S!()(x,y,z) and S(x,y,z)? How does
> either one of them make referring to the template 'S' difficult?
> Is there some conflicting syntax where the parentheses mean something else
> when S perceived as a template? Why isn't the same problem applicable to
> function templates?

That's a somewhat different consideration.

I agree that this working might be a good thing:

struct S(int n = 10)
{
    int a;
}

auto s = S(4);

where the type of the struct does not depend on the type of the parameters to the constructor. However, I'm not sold that full-on implicit template instantiation should apply to members. How would we deal with this situation:

struct S(T)
{
    this(T v) {}
}

auto s = S(4); //yay, compiler worked out S!int

later on someone does this:

struct S(T)
{
    this(Q v) if(is(Q : T)) {}
}

for whatever reason.

Now all those nice constructor calls to S(someValue) are broken.

I dunno, somehow the implicit behaviour seems ok when it's very local but it feels dodgy at the level of separation that there can be between constructors and their types.

On Thursday, 24 July 2014 at 11:39:13 UTC, Manu via Digitalmars-d wrote:
> On 24 July 2014 21:30, Manu <turkeyman@gmail.com> wrote:
>
>> On 24 July 2014 21:25, Manu <turkeyman@gmail.com> wrote:
>>
>>> On 24 July 2014 19:37, John Colvin via Digitalmars-d <
>>> digitalmars-d@puremagic.com> wrote:
>>>
>>>> On Thursday, 24 July 2014 at 04:53:41 UTC, Manu via Digitalmars-d wrote:
>>>>
>>>>> I'm running into consistent problems with default args and argument
>>>>> deduction in templates.
>>>>> There seem to be 2 consistent classes of problem:
>>>>>
>>>>> struct S(size_t len = 10)
>>>>> {
>>>>>   ubyte[len] data;
>>>>> }
>>>>>
>>>>> S!100 x; // this works fine
>>>>> S y; // this doesn't work (!)
>>>>> S!() z; // this works
>>>>>
>>>>> The template arg has a default arg, why require !() ??
>>>>> This causes problems in meta code, where you want to create an instance
>>>>> of
>>>>> some T, and T may be a normal type with no template args, in which case
>>>>> !()
>>>>> is invalid, but a template type with default args should also be
>>>>> acceptable, but it doesn't work because the meta code doesn't specify
>>>>> !().
>>>>>
>>>>
>>>> This opens a whole can of worms. It's very useful to be able to
>>>> distinguish between templates and their instantiations. Seeing as D's alias
>>>> system works on a pass-by-name system, you can't have a system where simply
>>>> referring to a template instantiates it with no arguments.
>>>>
>>>> Apart from anything else it would break *so* much code.
>>>>
>>>
>>> Isn't the call to the constructor enough to distinguish it is an
>>> instantiation rather than a reference to the template itself?
>>>
>>> S is a template
>>> S!() is a type
>>> S(x,y,z) is a call to it's constructor, the expression has a type
>>>
>>>  What is the useful distinction between S!()(x,y,z) and S(x,y,z)? How
>>> does either one of them make referring to the template 'S' difficult?
>>> Is there some conflicting syntax where the parentheses mean something
>>> else when S perceived as a template? Why isn't the same problem applicable
>>> to function templates?
>>>
>>
>> Ack! Sorry! I misread, your response as being related to the constructor
>> case, not the default arg case >_<
>>
>> I see the problem with the default arg case. It's a real shame, because it
>> has rather annoying side effects in generic code, and it doesn't appear to
>> follow the same logical rules as with functions.
>> This is precisely the sort of thing Scott Myers would be unhappy about...
>> Someone will need to 'explain' this for years to come, I don't think it's
>> intuitive ;)
>>
>
> Although... the more I think about it, the more I wonder why it matters if
> the syntax is ambiguous when the name is taken in isolation, that never
> actually happens...
> Why can't it just mean 'either the template, or the default arg
> instantiation', and be resolved when it's actually used?
> Is it possible for templates or types to both appear in the same context
> and create an actual ambiguity? What would that expression look like?
> The only place I can imagine a conflict could occur would be within an is()
> expression, but I'm not sure... can a uninstantiated template be used in an
> is() expression where a type would also be a meaningful fit?
>
> Generally, templates do this:
>   T!()
> And types do this:
>   T var;
>
> It's clear syntactically from 'T!()' that T is not a default args
> instantiation of T, because it's involved in a template instantiation
> expression.
> It's also clear from 'T var' that T is not a template, because a variable
> needs to have a type.

Seeing as templates can resolve to other templates, mixin templates, values, functions and types, the situation is complicated.

"Manu via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.274.1406201953.32463.digitalmars-d@puremagic.com...

Is it possible for templates or types to both appear in the same context and create an actual ambiguity? What would that expression look like?

alias X = T!U;

What is U?  Did you mean to pass the template or the type? 

On 24 July 2014 22:15, Daniel Murphy via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> "Manu via Digitalmars-d" <digitalmars-d@puremagic.com> wrote in message news:mailman.274.1406201953.32463.digitalmars-d@puremagic.com...
>
>
> Is it possible for templates or types to both appear in the same context and create an actual ambiguity? What would that expression look like?
>
> alias X = T!U;
>
> What is U?  Did you mean to pass the template or the type?
>

I didn't specify, and I don't think this code requires that I do.

T will resolve this situation naturally.
Is it 'template T(X)'? Obviously the type.
Is it 'template T(alias X)'? this could be the type or the template, but
since the template is more inclusive, it should be that. Within T's
definition, if T is passed as the template, then the opportunity is
retained to go either way as is necessary when the context becomes explicit.
I actually think it works quite elegantly. What have I missed?

On 24 July 2014 21:48, John Colvin via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

>
> That's a somewhat different consideration.
>
> I agree that this working might be a good thing:
>
> struct S(int n = 10)
> {
>     int a;
> }
>
> auto s = S(4);
>
> where the type of the struct does not depend on the type of the parameters to the constructor. However, I'm not sold that full-on implicit template instantiation should apply to members. How would we deal with this situation:
>
> struct S(T)
> {
>     this(T v) {}
> }
>
> auto s = S(4); //yay, compiler worked out S!int
>
> later on someone does this:
>
> struct S(T)
> {
>     this(Q v) if(is(Q : T)) {}
> }
>

That doesn't make any sense though. "Q : T" is not a 1:1 relationship, so
no deduction is possible there.
It makes equally little sense in the function case.
void f(T)(Q v) if(is(Q : T))
{
}

I only suggest that what would work for the function should equally work for the struct/class constructor.

for whatever reason.
>
> Now all those nice constructor calls to S(someValue) are broken.
>

Likewise if someone changed a function similarly.
I see no distinction from the function case, which I'm sure everyone agrees
is perfectly good how it is?

I dunno, somehow the implicit behaviour seems ok when it's very local but
> it feels dodgy at the level of separation that there can be between constructors and their types.
>

Not really sure what you mean. Constructors are absolutely tied to their type, that's the point of a constructor.

On 24 July 2014 22:03, John Colvin via Digitalmars-d < digitalmars-d@puremagic.com> wrote:

> On Thursday, 24 July 2014 at 11:39:13 UTC, Manu via Digitalmars-d wrote:

Although... the more I think about it, the more I wonder why it matters if
>> the syntax is ambiguous when the name is taken in isolation, that never
>> actually happens...
>> Why can't it just mean 'either the template, or the default arg
>> instantiation', and be resolved when it's actually used?
>> Is it possible for templates or types to both appear in the same context
>> and create an actual ambiguity? What would that expression look like?
>> The only place I can imagine a conflict could occur would be within an
>> is()
>> expression, but I'm not sure... can a uninstantiated template be used in
>> an
>> is() expression where a type would also be a meaningful fit?
>>
>> Generally, templates do this:
>>   T!()
>> And types do this:
>>   T var;
>>
>> It's clear syntactically from 'T!()' that T is not a default args
>> instantiation of T, because it's involved in a template instantiation
>> expression.
>> It's also clear from 'T var' that T is not a template, because a variable
>> needs to have a type.
>>
>
> Seeing as templates can resolve to other templates, mixin templates, values, functions and types, the situation is complicated.
>

This is just FUD without any case for consideration.
All of those different resolutions imply different syntactic contexts. I'm
still not sure of a case where a genuine ambiguity arises.

On 24/07/14 17:11, Manu via Digitalmars-d wrote:

> I didn't specify, and I don't think this code requires that I do.
>
> T will resolve this situation naturally.
> Is it 'template T(X)'? Obviously the type.
> Is it 'template T(alias X)'? this could be the type or the template, but
> since the template is more inclusive, it should be that. Within T's
> definition, if T is passed as the template, then the opportunity is
> retained to go either way as is necessary when the context becomes explicit.
> I actually think it works quite elegantly. What have I missed?

I'm pretty sure I've asked the same question as you did. I also got similar replays. To me it's quite simple. In every case it will be the template, as it is now. Except when called with arguments as a constructor.

-- 
/Jacob Carlborg