<div dir="ltr"><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 dir="ltr"><div class="gmail_quote"><span>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></span></div><div class="gmail_quote"><br></div><div class="gmail_quote">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><br></div><div>Yes, my hope is that this can be moved to a warning, and others have expressed the same thought to me.</div><div><br></div><div>There are two main issues that need to be addressed before this can be made a warning:</div><div><ul><li>I suspect (though I haven't measured) that the implementation isn't currently efficient enough to be made a Clang warning.<br></li><li>There are a number of scenarios in which the check warns when arguably it should not. These are:</li><ul><li>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>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><li>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"><div class="gmail_extra"><div class="gmail_quote"><div>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><br></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><br></div><div>Since you say this is a much-requested warning: Any pointers to previous discussions that I should be aware of?<br><blockquote style="margin:0 0 0 40px;border:none;padding:0px"><div class="gmail_extra"><div class="gmail_quote"><div><br></div></div></div></blockquote><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 dir="ltr"><div class="gmail_quote"><span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
See user-facing documentation for details.<br class="m_-6413569643389604814m_-7327215925212525831gmail_msg"></blockquote><div><br></div></span><div>In general, I suspect at least some more context should be provided in change descriptions. =]</div></div></div>
</blockquote></div><br><div>Thanks -- still new to this.</div><div><br></div><div>The intent was not to repeat myself, but I evidently went a bit far with that. ;) Is it of value if I provide a short summary on this thread, or is this just something I should keep in mind for future patches?</div>
</div></div></div>