<div dir="ltr"><div>I see it as very much like FTAD, which also has no explicit opt-in mechanism, and client programmers who omit template argument lists for function templates also run the risk of deducing the wrong thing sometimes (my upcoming CPPCon talk includes examples of this). In both cases, the sign that the client programmer intends to rely on deduction is that they omit the template argument list. <br></div><div><br></div><div>I'm not surprised you didn't find the warning to be very helpful, and I predict the percentage of spurious warnings will only increase as programmers become more comfortable with deduction for constructors templates like they are for other function templates.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Aug 3, 2019 at 9:14 AM Arthur O'Dwyer via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org">cfe-dev@lists.llvm.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr"><div dir="ltr">On Sat, Aug 3, 2019 at 6:03 AM JVApen via cfe-dev <<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Hello all,<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I'm currently testing 9.0.0 and I'm one of those strange people that uses -Weverything in production, as we only support a single clang-release at the same time. (Actually clang-cl, as it's Windows-only)<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">During the upgrade, I've noticed a new warning "-Wctad-maybe-unsupported".<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">At first, I was really happy seeing it and started updating some code that implicitly used it.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I'm even considering to propose an extension to our styleguide, as mentioned in the review of the warning: <a href="https://reviews.llvm.org/D56731" target="_blank">https://reviews.llvm.org/D56731</a></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">`Some style guides want to allow using CTAD only on types that "opt-in"`<br></div><div><br></div><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">However, after finishing my initial testing and applying some suppression and update locally, I'm changing my mind.<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">Over half of the updates I had to do were about `std::unique_lock`, `std::scope_guard` ... (and this without actively using this feature).<br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">These classes, if I'm correct, are one of the selling point of CTAD and are prohibited thanks to this warning.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">To circle back to title of the email, should -Wctad-maybe-unsupported actually be a compiler warning iso a clang-tidy check?<br></div></div></div></blockquote><div><br></div><div>(You mean "should -Wctad-maybe-unsupported be a clang-tidy check instead of a compiler warning?", I assume.)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">If so, would it make sense of having a white-list, like all `std::` classes?<br></div></div></div></blockquote><div><br></div><div>FWIW, I continue to believe that it makes no sense to talk about the <i><b>library author</b></i> "opting in" to CTAD. Either the <i><b>client programmer</b></i> trusts CTAD (even if it runs the risk of deducing the wrong thing sometimes) and thus every set-of-missing-angle-brackets must be assumed to be intentional no matter what type it's on, or else the client programmer doesn't trust CTAD (because of the aforementioned risk), and thus every set-of-missing-angle-brackets must be assumed to be unintentional. The intentions of the <i><b>library author</b></i> don't matter at all in this equation.</div><div><br></div><div>The situation for me is exactly analogous to VLAs in C — including the shape of the workaround: "write an explicit call to malloc()" versus "write an explicit call to make_foo()".</div><div><a href="https://reviews.llvm.org/D54565" target="_blank">https://reviews.llvm.org/D54565</a> implements a `-Wctad` warning analogous to `-Wvla`.</div><div><br></div><div>–Arthur</div></div></div></div>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
<a href="https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev</a><br>
</blockquote></div>