<div dir="ltr"><br><div class="gmail_quote"><div dir="ltr"><div class="gmail_extra">I am attaching a revision of the patch based on the last comments.</div><div class="gmail_extra"><br><br><div class="gmail_quote"><div class="im">
On Thu, May 30, 2013 at 5:54 PM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Thu, May 30, 2013 at 4:35 PM, Larisse Voufo <span dir="ltr"><<a href="mailto:lvoufo@google.com" target="_blank">lvoufo@google.com</a>></span> wrote:<br>
<div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="ltr">Please see attached.</div></blockquote><div><br></div><div>This looks really good.</div><div><br></div><div>Something funny has happened around < >s for templates. I've run the patch through clang-format for you (attached).</div>
</div></blockquote><div> </div></div><div>Thanks. It looks like my editor cannot tell template arguments' brackets from binary operators, and defaults into the later option. I'll be more careful about that. </div>
<div class="im">
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote">
<div><br></div><div><br></div><div><div>+ // Fixme: this assumes that both types will be equally</div><div>+ // restrict-qualified.</div></div><div><br></div><div>s/Fixme/FIXME/</div><div> <br>
</div></div></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div>
</div><div><div><br></div><div>+ if (ToType.isMoreQualifiedThan(CurToType))</div><div>+ ToType = CurToType;</div></div><div><br></div><div>The standard doesn't seem very clear on this, but I think you should merge qualifiers here rather than taking the more-qualified type. If we have a conversion to 'const T' and a conversion to 'volatile T', our current choice between them seems to depend on the order in which we see them.</div>
<div><br></div></div></blockquote></div><div>Ah. Good point. Following this train or reasoning, we should be looking for the least common qualifier between the conversion candidates. </div><div>However, as you pointed out earlier, the standard does suggest to just drop the qualifiers. I have made the change (cf. attached).</div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="gmail_quote"><div></div><div><br></div><div><div>+ if (ConvTemplate)</div><div>+ AddTemplateConversionCandidate(ConvTemplate, FoundDecl, ActingContext,</div><div>+ From, ToType, CandidateSet);</div>
</div><div><br></div><div>It looks like ViableConversions won't contain any conversion operator templates at this point. However, we should probably be performing overload resolution on the complete set of conversions, not just on the ones we matched earlier,</div>
</div></blockquote><div><br></div></div><div>Right. I have changed the meaning of ViableConversions for C++1y so that it contains *potentially* viable conversions, i.e. including conversion templates as well (again, cf. attached). </div>
<div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div> for oddball cases like:</div>
<div><br></div><div> struct A {</div><div> operator int() &&;</div><div> template<typename T> operator T();</div><div> };</div><div> void f(A a) {</div><div> switch (a) {} // should presumably call templated conversion operator to convert to int.</div>
<div> }</div><div> struct B {</div><div> operator bool() &&;</div><div> operator void*();</div><div> };</div><div> void g(B b) {</div><div> switch (b) {} // should presumably call 'b.operator void*()' then convert result to bool</div>
<div> }</div><div><br></div><div>The patch could do with more testcases, covering more exotic situations such as the above, and the new error cases.</div></div></blockquote></div><div>Sure. Working on that. I've added a unit tests. More test cases are welcome. :)</div>
<div>The above example is now covered. </div>
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="gmail_quote"><div><br></div><div>
Thanks!</div><span><font color="#888888"><div>
Richard</div></font></span></div>
</blockquote></div><br></div></div>
</div><br></div>