<div dir="ltr"><div dir="ltr" class="gmail_attr"><div dir="ltr"><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)"></span>On Sun, 4 Aug 2019 at 17:02, Arthur O'Dwyer <<a href="mailto:arthur.j.odwyer@gmail.com">arthur.j.odwyer@gmail.com</a>> wrote:<br></div></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 dir="ltr"><div dir="ltr">On Sun, Aug 4, 2019 at 5:25 AM JVApen <<a href="mailto:JVApen@gmail.com" target="_blank">JVApen@gmail.com</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 dir="ltr"></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 4 Aug 2019 at 00:37, Eric Fiselier <<a href="mailto:eric@efcs.ca" target="_blank">eric@efcs.ca</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">On Sat, Aug 3, 2019 at 10:14 AM Arthur O'Dwyer 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 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></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>Rewinding a bit: JVApen, could you explain a bit about why you felt the need to "update" code that used CTAD?</div><div>Also, you said "implicitly used" — is there any difference in your mind between "implicitly using" CTAD and "explicitly using" CTAD? What would the latter look like?</div></div></div></div></blockquote><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"></div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">At the moment, I don't have much reason to decide going either way. I'm trying to understand this new warning and if it's useful in our case. </div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">As I'm testing 9.0.0-RC1, I just want the warnings-as-error to disappear to tackle the actual issues.</div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default"></div></div><div><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">For the implicit part: As mentioned earlier, we didn't communicate about CTAD when introducing C++17, so right now I assume it's all implicitly introduced. For sure some are explicit by the few developers that follow the news about C++ standardization. I was planning to find out on Monday.<br></div></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 dir="ltr"><div class="gmail_quote"><div><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 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 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 dir="ltr"><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)">Over half of the updates I had to do were about `std::unique_lock`, `std::scope_guard` ... (and this without actively using this feature).</div></div></blockquote></div></div></div></blockquote></div></div></blockquote></div></div></blockquote><div><br></div><div>This implies that there were also some cases where people were using CTAD on types that weren't unique_lock or [I assume you meant scoped_lock/lock_guard, not scope_guard]. What's your opinion of those cases? While updating the code, did you find any usages of CTAD that were actually incorrect and/or unintentional?</div><div>How would you tell whether a use of CTAD was intentional or unintentional?</div><div><br></div></div></div></div></blockquote><div style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)" class="gmail_default">See previous: At the moment, I don't. </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 dir="ltr"><div class="gmail_quote"><div></div><div><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 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 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 dir="ltr"><div class="gmail_quote"><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></div></div></blockquote></div></div></blockquote><div> </div><div><span class="gmail_default" style="font-family:verdana,sans-serif;font-size:small;color:rgb(0,0,0)">I'm not sure we are talking about the same thing here, from what I read in that review, it flags all usages of CTAD. While the warning I mentioned doesn't trigger if the deduction guide exists. Although both use-cases are relevant, I'm in the luxurious position of having a single C++ standard to work with (and worry about). </span></div></div></div></blockquote><div><br></div><div>In my experience, the existence of a deduction guide (written by the library programmer, reflecting only the extent of the library programmer's imagination) has no bearing on whether any particular usage of CTAD (written by the client programmer, often indicating a typo or thinko) is correct or not.</div><div><a href="https://godbolt.org/z/_EfVON" target="_blank">https://godbolt.org/z/_EfVON</a></div><div><br></div><div>–Arthur</div></div></div></div>
</blockquote></div></div>