www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - new DIP40: Template parameter deduction for constructors

reply Timothee Cour <thelastmammoth gmail.com> writes:
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).
May 12 2013
next sibling parent reply "timotheecour" <timothee.cour2 gmail.com> writes:
The link:
http://wiki.dlang.org/DIP40
The paper links mentioned in the abstract are given in this DIP.
May 12 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
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.

May 14 2013
next sibling parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/14/2013 10:04 AM, deadalnix wrote:
 On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:
 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.


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

it said 'Find all matching class/struct types in scope', isn't that enough or am I missing something? To clarify, I've added 3 out of scope structs named A in the example section to clarify that they won't be included in the overload set. see the ones marked '//not in scope'

I think the best here is to specify that the rule is the same than eponymous funtion and IFTY. Otherwise we'll have 2 different specs with small difference here and there. And that sucks.

There is no spec for the IFTI case. (i.e. what happens if the eponymous declaration inside the template is an overload set?)
May 14 2013
parent reply Timon Gehr <timon.gehr gmx.ch> writes:
On 05/14/2013 11:30 AM, Timon Gehr wrote:
 On 05/14/2013 10:04 AM, deadalnix wrote:
 On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:
 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.


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

it said 'Find all matching class/struct types in scope', isn't that enough or am I missing something? To clarify, I've added 3 out of scope structs named A in the example section to clarify that they won't be included in the overload set. see the ones marked '//not in scope'

I think the best here is to specify that the rule is the same than eponymous funtion and IFTY. Otherwise we'll have 2 different specs with small difference here and there. And that sucks.

There is no spec for the IFTI case. (i.e. what happens if the eponymous declaration inside the template is an overload set?)

DMD's strategy is roughly: use the first eponymous declaration that can be found without analysing the template body for IFTI, then use the first eponymous declaration in the analyzed template body to resolve the eponymous declaration after instantiation. --- import std.stdio; template fun(T){ int fun(double arg){ return 1; } int fun(T arg){ return 0; } } void main(){ writeln(fun(2)); } // error --- import std.stdio; template fun(T){ int fun(T arg){ return 0; } int fun(double arg){ return 1; } } void main(){ writeln(fun(2)); } // ok --- This has funny implications, as the compiler may decide to resolve to a different declaration than was used for IFTI later, without doing any kind of overload resolution within the template body. --- template fun(T){ int fun(T arg){ return 0; } static if(true) int fun(double arg){ return 1; } } pragma(msg, fun(2)); // 0 --- template fun(T){ static if(true) int fun(double arg){ return 1; } int fun(T arg){ return 0; } } pragma(msg, fun(2)); // 1 --- In the second case, instantiation is performed with the second function, so T is resolved to 'int', but in the end, the 'double' overload is called with an implicit conversion.
May 14 2013
parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/14/2013 05:08 PM, Kenji Hara wrote:
 ...

 Current dmd behavior is definitely a bug. Could you please file it in
 bugzilla?
 ...

http://d.puremagic.com/issues/show_bug.cgi?id=10083
May 14 2013
prev sibling parent Timon Gehr <timon.gehr gmx.ch> writes:
On 05/14/2013 09:28 AM, Timothee Cour wrote:
         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.

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


 it said  'Find all matching class/struct types in scope', isn't that
 enough or am I missing something?

Apparently. The point is that it is not always possible to determine all constructors before the template is instantiated. The DIP must state when and how it works and what happens if it does not.
 To clarify, I've added 3 out of scope structs named A in the example
 section to clarify that they won't be included in the overload set.
 see the ones marked '//not in scope'

I don't get this. (Also, why is it relevant to the discussion?) The following declaration: template A(T1){ struct A{ //not in scope unless T1 is explicitly instantiated this()(T1 a) {} } } Is the same declaration, modulo constraint, as the preceding struct A(T1) if (!isNumeric!T1) { this()(T1 a) {} }
May 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
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.
May 12 2013
prev sibling next sibling parent Jacob Carlborg <doob me.com> writes:
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
May 13 2013
prev sibling next sibling parent "Peter Alexander" <peter.alexander.au gmail.com> writes:
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.
May 13 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
Thanks for the feedback, I've clarified the deduction mechanism and
show how it falls back to normal function template deduction.
May 13 2013
prev sibling next sibling parent "Steven Schveighoffer" <schveiguy yahoo.com> writes:
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
May 13 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--047d7b874c72b17e2404dca51ef5
Content-Type: text/plain; charset=UTF-8

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.

--047d7b874c72b17e2404dca51ef5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Currently conditional compilation would stop IFTI.<div><br=
</div><div><div>template foo(T)</div><div>{</div><div>=C2=A0 =C2=A0 static=

</div><div>}</div><div>void main()</div> <div>{</div><div>=C2=A0 =C2=A0 foo(1); =C2=A0 // shouldn&#39;t work</div><d= iv>}</div></div><div><br></div><div class=3D"gmail_extra">Same as above, DI= P40 should prevent following case.</div><div class=3D"gmail_extra"><br></di= v><div class=3D"gmail_extra"> <div class=3D"gmail_extra">template foo(T)</div><div class=3D"gmail_extra">= {</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 struct foo</div><div class= =3D"gmail_extra">=C2=A0 =C2=A0 {</div><div class=3D"gmail_extra">=C2=A0 =C2= =A0 =C2=A0 =C2=A0 static if (is(T =3D=3D int))</div> <div class=3D"gmail_extra">=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 this(T= ) {}</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 }</div><div class=3D"gma= il_extra">}</div><div class=3D"gmail_extra">void main()</div><div class=3D"= gmail_extra">{</div><div class=3D"gmail_extra">=C2=A0 =C2=A0 foo(1); // als= o should not work</div> <div class=3D"gmail_extra">}</div><div><br></div>Kenji Hara</div><div class= =3D"gmail_extra"><br><div class=3D"gmail_quote">2013/5/14 Timothee Cour <sp= an dir=3D"ltr">&lt;<a href=3D"mailto:thelastmammoth gmail.com" target=3D"_b= lank">thelastmammoth gmail.com</a>&gt;</span><br> <blockquote class=3D"gmail_quote" style=3D"margin-top:0px;margin-right:0px;= margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-color= :rgb(204,204,204);border-left-style:solid;padding-left:1ex">Thanks for the = feedback, I&#39;ve clarified the deduction mechanism and<br> show how it falls back to normal function template deduction.<br> </blockquote></div><br></div></div> --047d7b874c72b17e2404dca51ef5--
May 13 2013
prev sibling next sibling parent "timotheecour" <timothee.cour2 gmail.com> writes:
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.
May 14 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--047d7b2e4ea046b37a04dca8951f
Content-Type: text/plain; charset=ISO-8859-1

 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.


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

it said 'Find all matching class/struct types in scope', isn't that enough or am I missing something? To clarify, I've added 3 out of scope structs named A in the example section to clarify that they won't be included in the overload set. see the ones marked '//not in scope' --047d7b2e4ea046b37a04dca8951f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <div class=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margi= n:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=3D"im"=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=

I think that should be consistent with the deduction mechanism proposed<br> in the DIP: foo is struct not in scope until template foo(T) is instantiate= d.<br></blockquote></div></blockquote><div>=A0</div><blockquote class=3D"gm= ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le= ft:1ex"> <div class=3D"im"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .= 8ex;border-left:1px #ccc solid;padding-left:1ex"> </blockquote></div> No it is not. The DIP states &quot;find all constructors&quot;.</blockquote=
<div><br></div><div>it said =A0&#39;<span style=3D"background-color:rgb(25=

d all matching class/struct types in scope&#39;, isn&#39;t that enough or a= m I missing something?</span></div> <div><span style=3D"background-color:rgb(255,255,255);font-family:sans-seri= f;font-size:13px;line-height:19.1875px"><br></span></div><div><span style= =3D"background-color:rgb(255,255,255);font-family:sans-serif;font-size:13px= ;line-height:19.1875px">To clarify,=A0</span>I&#39;ve added 3 out of scope = structs named A in the example section to clarify that they won&#39;t be in= cluded in the overload set.</div> <div>see the ones marked &#39;//not in scope&#39;</div><div><br></div><div>= =A0</div></div><br> --047d7b2e4ea046b37a04dca8951f--
May 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:
 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.


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

it said 'Find all matching class/struct types in scope', isn't that enough or am I missing something? To clarify, I've added 3 out of scope structs named A in the example section to clarify that they won't be included in the overload set. see the ones marked '//not in scope'

I think the best here is to specify that the rule is the same than eponymous funtion and IFTY. Otherwise we'll have 2 different specs with small difference here and there. And that sucks.
May 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 14 May 2013 at 09:30:01 UTC, Timon Gehr wrote:
 There is no spec for the IFTI case. (i.e. what happens if the 
 eponymous declaration inside the template is an overload set?)

I know, but solving one problem at a time usual lead to better result than all at once.
May 14 2013
prev sibling next sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Tuesday, 14 May 2013 at 09:56:14 UTC, Timon Gehr wrote:
 DMD's strategy is roughly: use the first eponymous declaration 
 that can be found without analysing the template body for IFTI, 
 then use the first eponymous declaration in the analyzed 
 template body to resolve the eponymous declaration after 
 instantiation.

 ---
 import std.stdio;
 template fun(T){
 	int fun(double arg){ return 1; }
 	int fun(T arg){ return 0; }
 }
 void main(){ writeln(fun(2)); } // error

 ---
 import std.stdio;
 template fun(T){
 	int fun(T arg){ return 0; }
 	int fun(double arg){ return 1; }
 }
 void main(){ writeln(fun(2)); } // ok

 ---

 This has funny implications, as the compiler may decide to 
 resolve to a different declaration than was used for IFTI 
 later, without doing any kind of overload resolution within the 
 template body.

 ---
 template fun(T){
 	int fun(T arg){ return 0; }
 	static if(true) int fun(double arg){ return 1; }
 }
 pragma(msg, fun(2)); // 0
 ---
 template fun(T){
 	static if(true) int fun(double arg){ return 1; }
 	int fun(T arg){ return 0; }
 }
 pragma(msg, fun(2)); // 1
 ---

 In the second case, instantiation is performed with the second 
 function, so T is resolved to 'int', but in the end, the 
 'double' overload is called with an implicit conversion.

That creative. But completely b0rken IMO
May 14 2013
prev sibling next sibling parent Kenji Hara <k.hara.pg gmail.com> writes:
--f46d043c7dde48945c04dcaf0093
Content-Type: text/plain; charset=UTF-8

2013/5/14 Timon Gehr <timon.gehr gmx.ch>

 On 05/14/2013 11:30 AM, Timon Gehr wrote:

 On 05/14/2013 10:04 AM, deadalnix wrote:

 On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:

 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.



it said 'Find all matching class/struct types in scope', isn't that enough or am I missing something? To clarify, I've added 3 out of scope structs named A in the example section to clarify that they won't be included in the overload set. see the ones marked '//not in scope'

I think the best here is to specify that the rule is the same than eponymous funtion and IFTY. Otherwise we'll have 2 different specs with small difference here and there. And that sucks.

There is no spec for the IFTI case. (i.e. what happens if the eponymous declaration inside the template is an overload set?)

DMD's strategy is roughly: use the first eponymous declaration that can be found without analysing the template body for IFTI, then use the first eponymous declaration in the analyzed template body to resolve the eponymous declaration after instantiation. --- import std.stdio; template fun(T){ int fun(double arg){ return 1; } int fun(T arg){ return 0; } } void main(){ writeln(fun(2)); } // error --- import std.stdio; template fun(T){ int fun(T arg){ return 0; } int fun(double arg){ return 1; } } void main(){ writeln(fun(2)); } // ok --- This has funny implications, as the compiler may decide to resolve to a different declaration than was used for IFTI later, without doing any kind of overload resolution within the template body. --- template fun(T){ int fun(T arg){ return 0; } static if(true) int fun(double arg){ return 1; } } pragma(msg, fun(2)); // 0 --- template fun(T){ static if(true) int fun(double arg){ return 1; } int fun(T arg){ return 0; } } pragma(msg, fun(2)); // 1 --- In the second case, instantiation is performed with the second function, so T is resolved to 'int', but in the end, the 'double' overload is called with an implicit conversion.

Current dmd behavior is definitely a bug. Could you please file it in bugzilla? Kenji Hara --f46d043c7dde48945c04dcaf0093 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">2013/5/14 Timon Gehr <span dir=3D"ltr">&lt;<a href=3D"mail= to:timon.gehr gmx.ch" target=3D"_blank">timon.gehr gmx.ch</a>&gt;</span><br=
<div class=3D"gmail_extra"><div class=3D"gmail_quote"><blockquote class=3D=

-left:1ex"> <div class=3D"HOEnZb"><div class=3D"h5">On 05/14/2013 11:30 AM, Timon Gehr = wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On 05/14/2013 10:04 AM, deadalnix wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"><blockquote class=3D"gmail_quote" style=3D"m= argin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> <br> I think that should be consistent with the deduction mechanism proposed<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> in the DIP: foo is struct not in scope until template foo(T) is<br> instantiated.<br> <br> </blockquote> <br> </blockquote> <br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex"> =C2=A0No it is not. The DIP states &quot;find all constructors&quot;.<br> </blockquote> <br> <br> it said =C2=A0&#39;Find all matching class/struct types in scope&#39;, isn&= #39;t that<br> enough<br> or am I missing something?<br> <br> To clarify, I&#39;ve added 3 out of scope structs named A in the example<br=

see the ones marked &#39;//not in scope&#39;<br> </blockquote> <br> I think the best here is to specify that the rule is the same than<br> eponymous funtion and IFTY. Otherwise we&#39;ll have 2 different specs with= <br> small difference here and there. And that sucks.<br> </blockquote> <br> There is no spec for the IFTI case. (i.e. what happens if the eponymous<br> declaration inside the template is an overload set?)<br> </blockquote> <br></div></div> DMD&#39;s strategy is roughly: use the first eponymous declaration that can= be found without analysing the template body for IFTI, then use the first = eponymous declaration in the analyzed template body to resolve the eponymou= s declaration after instantiation.<br> <br> ---<br> import std.stdio;<br> template fun(T){<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(double arg){ return 1; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(T arg){ return 0; }<br> }<br> void main(){ writeln(fun(2)); } // error<br> <br> ---<br> import std.stdio;<br> template fun(T){<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(T arg){ return 0; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(double arg){ return 1; }<br> }<br> void main(){ writeln(fun(2)); } // ok<br> <br> ---<br> <br> This has funny implications, as the compiler may decide to resolve to a dif= ferent declaration than was used for IFTI later, without doing any kind of = overload resolution within the template body.<br> <br> ---<br> template fun(T){<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(T arg){ return 0; }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 static if(true) int fun(double arg){ return 1; = }<br> }<br> pragma(msg, fun(2)); // 0<br> ---<br> template fun(T){<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 static if(true) int fun(double arg){ return 1; = }<br> =C2=A0 =C2=A0 =C2=A0 =C2=A0 int fun(T arg){ return 0; }<br> }<br> pragma(msg, fun(2)); // 1<br> ---<br> <br> In the second case, instantiation is performed with the second function, so= T is resolved to &#39;int&#39;, but in the end, the &#39;double&#39; overl= oad is called with an implicit conversion.<br></blockquote><div><br></div> <div style>Current dmd behavior is definitely a bug. Could you please file = it in bugzilla?</div><div style><br></div><div style>Kenji Hara</div></div>= </div></div> --f46d043c7dde48945c04dcaf0093--
May 14 2013
prev sibling next sibling parent Timothee Cour <thelastmammoth gmail.com> writes:
--047d7b471d9c9fbf7704dcd244f0
Content-Type: text/plain; charset=ISO-8859-1

ok Hara Kenji just fixed the bug, see
https://github.com/D-Programming-Language/dmd/pull/2041

So what's left unspecified now wrt DIP40?

My proposal was to just address case C2 below, not C1 (at least initially):

case C1:
template A(T1) {struct A{  this()(T1 a) {} }}

case C2:
struct A(T1){     this()(T1 a) {}}

Even though struct A(T1) may internally be implemented as template A(T1), I
think the most useful / less problematic conversion is just case C2.
In other words, as i said before, the constructors inside a template (as in
case C1) would note be considered as part of the overload set for this
DIP40 (at least initially).


On Tue, May 14, 2013 at 12:02 PM, Timon Gehr <timon.gehr gmx.ch> wrote:

 On 05/14/2013 05:08 PM, Kenji Hara wrote:

 ...


 Current dmd behavior is definitely a bug. Could you please file it in
 bugzilla?
 ...

http://d.puremagic.com/issues/**show_bug.cgi?id=10083<http://d.puremagic.com/issues/show_bug.cgi?id=10083>

--047d7b471d9c9fbf7704dcd244f0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable ok Hara Kenji just fixed the bug, see=A0<a href=3D"https://github.com/D-Pro= gramming-Language/dmd/pull/2041">https://github.com/D-Programming-Language/= dmd/pull/2041</a><div><br></div><div>So what&#39;s left unspecified now wrt= DIP40?</div> <div><br></div><div>My proposal was to just address case C2 below, not C1 (= at least initially):</div><div><br></div><div><font color=3D"#222222" face= =3D"arial, sans-serif">case C1:</font><br style=3D"color:rgb(34,34,34);font= -family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"> <span style=3D"background-color:rgb(255,255,255);color:rgb(34,34,34);font-f= amily:arial,sans-serif;font-size:13px">template A(T1) {</span><span style= =3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;backgro= und-color:rgb(255,255,255)">struct A{</span><span style=3D"font-size:13px;c= olor:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,25= 5,255)">=A0 this()(T1 a) {}=A0</span><span style=3D"font-size:13px;color:rg= b(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255,255)"=
}</span><span style=3D"font-size:13px;color:rgb(34,34,34);font-family:aria=

<div><span style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sa= ns-serif;background-color:rgb(255,255,255)"><br></span></div><div><font col= or=3D"#222222" face=3D"arial, sans-serif">case C2:=A0</font><br style=3D"fo= nt-size:13px;color:rgb(34,34,34);font-family:arial,sans-serif;background-co= lor:rgb(255,255,255)"> </div><div><div><span style=3D"font-size:13px;color:rgb(34,34,34);font-fami= ly:arial,sans-serif;background-color:rgb(255,255,255)">struct A(T1)</span><= span style=3D"font-size:13px;color:rgb(34,34,34);font-family:arial,sans-ser= if;background-color:rgb(255,255,255)">{=A0</span><span style=3D"font-size:1= 3px;color:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(2= 55,255,255)">=A0 =A0 this()(T1 a) {}</span><span style=3D"font-size:13px;co= lor:rgb(34,34,34);font-family:arial,sans-serif;background-color:rgb(255,255= ,255)">}</span></div> </div><div><br></div><div>Even though struct A(T1) may internally be implem= ented as=A0<span style=3D"background-color:rgb(255,255,255);color:rgb(34,34= ,34);font-family:arial,sans-serif;font-size:13px">template A(T1), I think t= he most useful / less problematic conversion is just case C2.</span></div> <div><span style=3D"background-color:rgb(255,255,255);color:rgb(34,34,34);f= ont-family:arial,sans-serif;font-size:13px">In other words, as i said befor= e,=A0</span><span style=3D"background-color:rgb(255,255,255);color:rgb(34,3= 4,34);font-family:arial,sans-serif;font-size:13px">the constructors inside = a template (as in case C1) would note be considered as part of the overload= set for this DIP40 (at least initially).=A0</span></div> <div><span style=3D"background-color:rgb(255,255,255);color:rgb(34,34,34);f= ont-family:arial,sans-serif;font-size:13px"><br></span></div><div><br></div=
<div><div class=3D"gmail_quote">On Tue, May 14, 2013 at 12:02 PM, Timon Ge=

ank">timon.gehr gmx.ch</a>&gt;</span> wrote:<br> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p= x #ccc solid;padding-left:1ex">On 05/14/2013 05:08 PM, Kenji Hara wrote:<br=

x #ccc solid;padding-left:1ex"> ...<div class=3D"im"><br> <br> Current dmd behavior is definitely a bug. Could you please file it in<br> bugzilla?<br></div> ...<br> </blockquote> <br> <a href=3D"http://d.puremagic.com/issues/show_bug.cgi?id=3D10083" target=3D= "_blank">http://d.puremagic.com/issues/<u></u>show_bug.cgi?id=3D10083</a><b= r> <br> </blockquote></div><br></div> --047d7b471d9c9fbf7704dcd244f0--
May 16 2013
prev sibling parent "deadalnix" <deadalnix gmail.com> writes:
On Thursday, 16 May 2013 at 09:12:53 UTC, Timothee Cour wrote:
 Even though struct A(T1) may internally be implemented as 
 template A(T1), I
 think the most useful / less problematic conversion is just 
 case C2.

It may not. It is, by definition.
May 16 2013