<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/11/4 Jon Eyolfson <span dir="ltr"><<a href="mailto:jon@eyolfson.com" target="_blank">jon@eyolfson.com</a>></span><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Hello Clang Developers,<br>
<br>
In my brief time with the clang codebase I've noticed instances of const_cast<br>
and mutable I don't believe are necessary. Are the uses of const_cast and<br>
mutable just temporary to avoid some compile-time type errors?  </blockquote><div><br></div><div>Some might be temporary, there are varying levels of 'technical debt' that are acceptable/accrued/historical. Some might be deliberate/acceptable. It's hard to say generally.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Does const have<br>
a different meaning for internal clang code?</blockquote><div><br></div><div>Not especially, though there are perhaps some quirks. One is that if an class represents immutable objects then we may not bother using 'const' at all, since all instances will always be const, we just drop the 'const' from all instances. (see the llvm::Type hierarchy for an example of that)<br>
</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> Is developer time prioritized<br>
elsewhere and you're looking for contributors to help with const-correctness?<br></blockquote><div><br></div><div>Possibly.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<br>
The attached example diff demonstrates what I believe is a const-correct version<br>
of CFGBlock::getTerminatorCondition(). I don't understand the reasoning behind<br>
including a non-const version of this member function that may unintentionally<br>
allow bad client code.<br></blockquote><div><br></div><div>What bad client code do you think this might unintentionally allow?<br><br>I believe this code just provided a const and non-const overload for the convenience of users (arguable as to whether that's necessary at all, but evidently no one relies on it at the moment if your code change compiles). It just happens to be easier to implement the overloads by having one overload defer to the other.<br>
<br>Personally I probably would've had the non-const overload defer to the const overload (and const_cast the result) as that would be more correct than possibly casting away const on an actually const object to call a non-const member function from a const member function.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
After applying the diff, clang and the default plugins compile successfully as<br>
expected. Granted I don't have any other client code, so I can't see their uses<br>
(or misuses). I would argue that bad client code would now get a helpful error<br>
message instead of possibly really breaking something in the future. Clients can<br>
either fix their code or be explicit about breaking const and include the<br>
const_cast themselves.<br>
<br>
This is my first email to a mailing list, so I apologize in advance for<br>
any misuse.<br>
<span class="HOEnZb"><font color="#888888"><br>
Jon<br>
</font></span><br>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
<br></blockquote></div><br></div></div>