<div dir="ltr">2013/5/14 Timon Gehr <span dir="ltr"><<a href="mailto:timon.gehr@gmx.ch" target="_blank">timon.gehr@gmx.ch</a>></span><br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 05/14/2013 11:30 AM, Timon Gehr wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 05/14/2013 10:04 AM, deadalnix wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tuesday, 14 May 2013 at 07:28:57 UTC, Timothee Cour wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin: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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #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="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
 No it is not. The DIP states "find all constructors".<br>
</blockquote>
<br>
<br>
it said  'Find all matching class/struct types in scope', isn't that<br>
enough<br>
or am I missing something?<br>
<br>
To clarify, I've added 3 out of scope structs named A in the example<br>
section to clarify that they won't be included in the overload set.<br>
see the ones marked '//not in scope'<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'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'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.<br>

<br>
---<br>
import std.stdio;<br>
template fun(T){<br>
        int fun(double arg){ return 1; }<br>
        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>
        int fun(T arg){ return 0; }<br>
        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 different 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>
        int fun(T arg){ return 0; }<br>
        static if(true) int fun(double arg){ return 1; }<br>
}<br>
pragma(msg, fun(2)); // 0<br>
---<br>
template fun(T){<br>
        static if(true) int fun(double arg){ return 1; }<br>
        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 'int', but in the end, the 'double' overload 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>