A proposed feature of C++14 is to introduce template parameter
deduction for constructors, see paper, mentioned here. The idea is to
deduce template parameters when calling a constructor given the
arguments given to the constructor, whenever possible. A compile error
occurs when the deduction is ambiguous. The benefits would be:
* make the code more DRY
* make boilerplate of class instantiators unnecessary in most cases
(they're all over phobos, eg: std.typecons.tuple,
std.typecons.rebindable etc)
* make D more consistent: it deduces template parameters for
functions, so why not for constructors, when this is unambiguous?
* it won't break any code.
Note, just as for deduction of normal functions, it should work with 0
or more template parameters specified (ie the first k>=0 templates may
be provided).

The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.

On Monday, 13 May 2013 at 02:39:22 UTC, timotheecour wrote:
> The link:
> http://wiki.dlang.org/DIP40
> The paper links mentioned in the abstract are given in this DIP.

Not the first time it is mentioned. Definitively a direction we want to take.

On 2013-05-13 04:37, Timothee Cour wrote:
> A proposed feature of C++14 is to introduce template parameter
> deduction for constructors, see paper, mentioned here. The idea is to
> deduce template parameters when calling a constructor given the
> arguments given to the constructor, whenever possible. A compile error
> occurs when the deduction is ambiguous. The benefits would be:
> * make the code more DRY
> * make boilerplate of class instantiators unnecessary in most cases
> (they're all over phobos, eg: std.typecons.tuple,
> std.typecons.rebindable etc)
> * make D more consistent: it deduces template parameters for
> functions, so why not for constructors, when this is unambiguous?
> * it won't break any code.
> Note, just as for deduction of normal functions, it should work with 0
> or more template parameters specified (ie the first k>=0 templates may
> be provided).

I definitely want this.

-- 
/Jacob Carlborg

On Monday, 13 May 2013 at 02:39:22 UTC, timotheecour wrote:
> The link:
> http://wiki.dlang.org/DIP40
> The paper links mentioned in the abstract are given in this DIP.

This DIP is lacking in detail.

struct A(T1)
if(!is(T1==float))
{
	this(T2)(T2 a, T1 b){}
	this()(T1 b){}
	this()(){}
}
struct A(T1)
if(is(T1==float))
{
	this()(){}
}

auto a=A(1,1.0); //deduced to A!(double)(1,1.0)
auto a=A(1.0); //deduced to A!(double)(1.0)
auto a=A(); //error: T1 cannot be deduced.


How does the compiler decide which templates to attempt to instantiate? Does it just ignore conditional compilation conditions? If so, what would it do with this?

struct A(T)
if (is(T==float) && is(T!=float))
{
    this()(T a) {}
}


If the conditions are ignored then it will match this uninstantiable template. If it doesn't ignore the conditions then how does it determine T ahead of time to evaluate the conditions?

One possible solution could be to first ignore the conditions, match the constructor, then check that the condition is okay. This is an extension on how normal function type deduction works though, so whatever mechanisms you have in mind need to be part of the proposal.

Thanks for the feedback, I've clarified the deduction mechanism and show how it falls back to normal function template deduction.

On Sun, 12 May 2013 22:37:43 -0400, Timothee Cour <thelastmammoth@gmail.com> wrote:

> A proposed feature of C++14 is to introduce template parameter
> deduction for constructors, see paper, mentioned here. The idea is to
> deduce template parameters when calling a constructor given the
> arguments given to the constructor, whenever possible. A compile error
> occurs when the deduction is ambiguous. The benefits would be:
> * make the code more DRY
> * make boilerplate of class instantiators unnecessary in most cases
> (they're all over phobos, eg: std.typecons.tuple,
> std.typecons.rebindable etc)
> * make D more consistent: it deduces template parameters for
> functions, so why not for constructors, when this is unambiguous?
> * it won't break any code.
> Note, just as for deduction of normal functions, it should work with 0
> or more template parameters specified (ie the first k>=0 templates may
> be provided).

Definitely need/want this.

I say it is most definitely possible given how IFTI works (it must partially instantiate the template).  It should be noted that conditional compilation can stop this from working.  As a first step, it should have exactly the same rules as IFTI, assuming the constructor is the eponymous IFTI function.

BTW, related issue:  http://d.puremagic.com/issues/show_bug.cgi?id=6082 with 4 votes so far

Added a link there.

-Steve

Currently conditional compilation would stop IFTI.

template foo(T)
{
    static if (is(T == int))
        void foo(T) {}
}
void main()
{
    foo(1);   // shouldn't work
}

Same as above, DIP40 should prevent following case.

template foo(T)
{
    struct foo
    {
        static if (is(T == int))
            this(T) {}
    }
}
void main()
{
    foo(1); // also should not work
}

Kenji Hara

2013/5/14 Timothee Cour <thelastmammoth@gmail.com>

> Thanks for the feedback, I've clarified the deduction mechanism and show how it falls back to normal function template deduction.
>

On Tuesday, 14 May 2013 at 03:20:59 UTC, Kenji Hara wrote:
> Currently conditional compilation would stop IFTI.
>
> template foo(T)
> {
>     static if (is(T == int))
>         void foo(T) {}
> }
> void main()
> {
>     foo(1);   // shouldn't work
> }
>
> Same as above, DIP40 should prevent following case.
>
> template foo(T)
> {
>     struct foo
>     {
>         static if (is(T == int))
>             this(T) {}
>     }
> }
> void main()
> {
>     foo(1); // also should not work
> }
>
> Kenji Hara


I think that should be consistent with the deduction mechanism proposed in the DIP:
foo is struct not in scope until template foo(T) is instantiated.

On 05/14/2013 09:06 AM, timotheecour wrote:
> On Tuesday, 14 May 2013 at 03:20:59 UTC, Kenji Hara wrote:
>> Currently conditional compilation would stop IFTI.
>>
>> template foo(T)
>> {
>>     static if (is(T == int))
>>         void foo(T) {}
>> }
>> void main()
>> {
>>     foo(1);   // shouldn't work
>> }
>>
>> Same as above, DIP40 should prevent following case.
>>
>> template foo(T)
>> {
>>     struct foo
>>     {
>>         static if (is(T == int))
>>             this(T) {}
>>     }
>> }
>> void main()
>> {
>>     foo(1); // also should not work
>> }
>>
>> Kenji Hara
>
>
> I think that should be consistent with the deduction mechanism proposed
> in the DIP:

No it is not. The DIP states "find all constructors".

> foo is struct not in scope until template foo(T) is instantiated.