<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 8, 2014 at 7:20 PM, Nick Kledzik <span dir="ltr"><<a href="mailto:kledzik@apple.com" target="_blank">kledzik@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>The lld conventions for ivars is a leading underscore followed by a lowercase letter.  The reserved identifiers are a leading underscore followed by an uppercase letter.  There is no conflict.</div></div></blockquote><div><br></div><div>And I didn't say that there was. They are *close*. Too close. People make mistakes and get it wrong.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><br></div><div>On the other hand the LLVM conventions prevents the use of the -Wshadow which catches real bugs.</div></div></blockquote><div><br></div><div>I don't think this is inherently true. I would have no trouble working to fix existing shadows in LLVM and turn on the warning.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><span class=""><div><br></div><br><blockquote type="cite"><div dir="ltr"><div class="gmail_extra"><br></div><div class="gmail_extra">However, I care much less about the particular naming convention than that we have a consistent naming convention. And changing LLD to LLVM's style and then later changing LLVM's style (and all the subprojects) will not appreciably increase the amount of churn required to the project as a whole. So I don't think we should hold up progress in the pursuit of perfection here.</div></div>
</blockquote></span></div><br><div>So you are saying, let’s make lld’s code worse and maybe someday make lld’s and llvm’s code better.  </div></blockquote><div><br></div><div>That's a very LLD-centric way of looking at it.</div><div><br></div><div>I'm saying let's make the entire LLVM project better by being more consistent between subprojects. Maybe someday we can make that consistent state also a better state. But avoiding consistency until that arrives is, in my opinion, blocking progress in the name of perfection. I would rather incremental progress.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br></div><div>Why not hold off on changing lld until the broader naming convention is decided, then change lld to that?  lld has been using these conventions for years.  What is the rush?</div></blockquote><div><br></div><div>The rush is that more and more people would *like* to start contributing to LLD. But they have to continually try to remember to deal with the inconsistencies between the two codebases. That wastes peoples time and discourages new contributors.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>  Besides, if you strip the distinctive name from ivars, it will be hard to automatically add that back.</div></blockquote></div></div><br><div>The primary hope of changing all of LLVM's naming conventions is the ready availability of Clang-based tools to manage the migration. Such tools don't need distinctive names, they *know* which names are member variables.</div></div>