<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">On Aug 22, 2013, at 6:25 PM, Craig Topper <<a href="mailto:craig.topper@gmail.com">craig.topper@gmail.com</a>> wrote:<br><div><blockquote type="cite">On Thursday, August 22, 2013, John McCall  wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Aug 22, 2013, at 12:09 AM, Craig Topper <<a href="javascript:;" onclick="_e(event, 'cvml', 'craig.topper@gmail.com')">craig.topper@gmail.com</a>> wrote:<br>

> Author: ctopper<br>
> Date: Thu Aug 22 02:09:37 2013<br>
> New Revision: 188991<br>
><br>
> URL: <a href="http://llvm.org/viewvc/llvm-project?rev=188991&view=rev" target="_blank">http://llvm.org/viewvc/llvm-project?rev=188991&view=rev</a><br>
> Log:<br>
> Constify more uses of ASTContext&. No functional change.<br>
<br>
Is this actually useful?  Are there interesting bugs we can catch by<br>
distinguishing a const vs. a non-const ASTContext?<br>
<br>
I mean, having const AST nodes makes sense inasmuch as the AST is not<br>
fully immutable after construction and it’s useful to record that consumers<br>
are not supposed to modify the AST.  But who actually cares about having<br>
a const ASTContext?<br>
<br>
Because if it’s not catching real bugs, it’s just adding a ton of noise to the<br>
code, and we should just say that you always have a non-const ASTContext<br>
the same way that you always pass around non-const llvm::Type*s.<br>
<br>
John.</blockquote><div><br></div><div>Somebody in the past went to the trouble of marking thing const and mutable within the ASTContext. I believe with Type there are no methods that can actually modify it so its const by construction.</div>
<div><br></div><div>I have no strong feelings either way. If people want me to stop ill stop.<span></span></div></blockquote><div><br></div>Marking individual getters and setters as const can be useful documentation/checking even on types you don’t expect to ever see passed around as ‘const’.<br><div><br></div></div>I’d prefer to not see ‘const ASTContext&’ continue to propagate until someone justifies why it’s useful.<div><br></div><div>My feeling is that, all else aside, there are too many ways to get a redundant reference to the ASTContext& for this kind of const marking to be effective.<br><div><br></div><div>John.</div></div></body></html>