<div dir="ltr"><div class="gmail_extra"><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></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div><span class=""><blockquote type="cite"><div dir="ltr"><div class="gmail_extra">Sure, I actually have no problem with this.</div><div class="gmail_extra"><br></div><div class="gmail_extra">I'm going to point out that one of the naming conventions used by LLD has serious problems: naming variables with a leading underscore puts them *way* too close to the reserved identifier space. Folks have accidentally ended up with reserved names quite a few times already.</div></div></blockquote></span><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><br></div><div>On the other hand the LLVM conventions prevents the use of the -Wshadow which catches real bugs.</div></div></div></blockquote><div><br></div><div>If people think this is a valuable warning, we should just fix it so that it doesn't fire on this common pattern:</div><div>struct A {</div><div>  A(int x) : x(x) {}</div><div>  int x;<br>};</div><div><br></div><div>It should still fire on this pattern though:</div><div><div>struct A {</div><div>  A(int x) : x(x) { x++; } // I modified the parameter 'x', not the member 'x'.</div><div>  int x;<br>};</div></div><div><br></div><div>We shouldn't create conventions just to work around bugs in a toolchain that we control.</div><div><br></div><div>---</div><div><br></div><div>My two cents: LLVM's conventions around method names and local variable names are widely ignored. For example, the IRBuilder uses leading capitals for methods. Clang CodeGen does as well. Clang CodeGen also uses lots of local variables with leading lower-case letters, which is against the variable naming guidelines.</div><div><br></div><div>I think the takeaway from that is that lots of people don't actually understand or agree with the LLVM naming standards in this area. I don't think we should do a mass rename in LLD if we aren't willing to do a mass rename across Clang internals, and so far no one has indicated a desire to do that.</div><div><br></div><div>If we limit the scope of the proposed change to removing leading underscores from fields, then that might be worth doing, but it's really up to you folks. I just don't think we're ready for a function and variable case unification yet.</div></div></div></div>