Template argument deduction and default args

Manu via Digitalmars-d digitalmars-d at puremagic.com
Thu Jul 24 08:18:27 PDT 2014


On 24 July 2014 21:48, John Colvin via Digitalmars-d <
digitalmars-d at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20140725/1c5e61b9/attachment-0001.html>


More information about the Digitalmars-d mailing list