On 24 July 2014 21:48, John Colvin via Digitalmars-d <
[email protected]> 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.
