<div dir="ltr">(Somehow I missed this, sorry for silence...)<br><br><div class="gmail_quote"><div dir="ltr">On Wed, Sep 14, 2016 at 6:13 AM Martin Böhme <<a href="mailto:mboehme@google.com">mboehme@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_quote gmail_msg"><span class="gmail_msg">While I'm excited to see this go in anywhere, I have to say I'm a bit sad it isn't going in as a warning and instead inside clang-tidy. This has been a much requested warning from Clang for many years.<br class="gmail_msg"></span></div><div class="gmail_quote gmail_msg"><br class="gmail_msg"></div><div class="gmail_quote gmail_msg">Is there a concise description of why this design was chosen? Are there specific problems that make it infeasible to be a warnings? Is there maybe a plan to move it to a warning after some set of issues are addressed?</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">Yes, my hope is that this can be moved to a warning, and others have expressed the same thought to me.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">There are two main issues that need to be addressed before this can be made a warning:</div><div class="gmail_msg"><ul class="gmail_msg"><li class="gmail_msg">I suspect (though I haven't measured) that the implementation isn't currently efficient enough to be made a Clang warning.<br class="gmail_msg"></li><li class="gmail_msg">There are a number of scenarios in which the check warns when arguably it should not. These are:</li><ul class="gmail_msg"><li class="gmail_msg">User-defined types that make guarantees about the state of a moved-from object (in the way that std::unique_ptr and std::shared_ptr do). Some form of annotation could be used to indicate that this is the case.</li><li class="gmail_msg">User-defined types that provide a member function to reinitialize the entire object (the way that clear() does on the standard container classes). These could either again be annotated in some way, or we could simply assume that any non-const member function reinitializes the object.</li></ul></ul></div></div></div></div></blockquote><div>I think it would be good to have a general design discussion about what the semantic model should be here. I have a somewhat specific and precise idea of what C++ is going for here based on several previous (extensive) conversations about this with Richard Smith, David Blaikie, and DeLesley Hutchins. Notably, DeLesley worked on this and closely related warnings in Clang for quite some time.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><ul class="gmail_msg"><ul class="gmail_msg"><li class="gmail_msg">Tests for move constructors / move assignment operators. Often, these tests check that a moved-from object is left in a certain state, even if the class in question does not provide such a guarantee to clients (the intent being to check that the move constructor / move assignment operator do not simply perform a copy).</li></ul></ul></div></div></div><blockquote style="margin:0 0 0 40px;border:none;padding:0px" class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">All of these scenarios are probably somewhat controversial, but I don't think there's a broad consensus that any of them should be prohibited, so there needs to be a way to silence the warning in these cases.</div></div></div></blockquote></div></blockquote><div><br></div><div>The first two are actually pretty critical features of some types, so yea, this will end up needing to be directly supported.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div>I do hope to resolve these issues and make this check into a warning, but in the meantime, having it available as a clang-tidy check seems like a good way to gather feedback and gain experience with it.<div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Since you say this is a much-requested warning: Any pointers to previous discussions that I should be aware of?<br class="gmail_msg"></div></div></blockquote><div><br></div><div>Searching the interwebs finds at least:</div><div><a href="http://lists.llvm.org/pipermail/cfe-dev/2014-October/039468.html">http://lists.llvm.org/pipermail/cfe-dev/2014-October/039468.html</a><br></div><div><br></div><div>I know internally our users have asked for this repeatedly, I'll send you info there.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr" class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg">
</div></div></div>
</blockquote></div></div>