<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Mar 1, 2014 at 10:41 PM, Chris Lattner <span dir="ltr"><<a href="mailto:clattner@apple.com" target="_blank">clattner@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 class=""><br>
On Feb 28, 2014, at 6:44 PM, Chandler Carruth <<a href="mailto:chandlerc@gmail.com">chandlerc@gmail.com</a>> wrote:<br>
> I talked to Richard Smith, Doug Gregor, and John McCall (as some of the more language oriented folks in the community), and with their help I came up with these additions to the coding standards. I'd like to get some broader input on these, but ideally I'd like to paint these bikesheds pretty quickly, put something in place, and revisit them if these guidelines don't really work out in practice.<br>

><br>
> <a href="http://llvm-reviews.chandlerc.com/D2905" target="_blank">http://llvm-reviews.chandlerc.com/D2905</a><br>
<br>
</div>Overall, lgtm, a couple of suggested additions:<br></blockquote><div><br></div><div>Thanks! Submitted in r202620. If there are further tweaks, we can do them in subsequent commits.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class=""><br>
> +Format Lambdas Like Blocks Of Code<br>
> +""""""""""""""""""""""""""""""""""<br>
> +<br>
> +When formatting a multi-line lambda, format it like a block of code, that's<br>
> +what it is. If there is only one multi-line lambda in a statement, and there<br>
> +are no expressions lexically after it in the statement, drop the indent to the<br>
> +standard two space indent for a block of code, as if it were an if-block opened<br>
> +by the preceding part of the statement:<br>
<br>
</div>Related to lambdas, it is worth mentioning that any functions which take std::functions should do so as their last argument.  You don't want a lambda body to come before a bunch of other random arguments.<br>
<br>
This has been the standard apple API standard for "blocks" and has worked out really well.<br></blockquote><div><br></div><div>Same here as well. I like it. I'll add this in a separate commit, and let me know if you have any issues with the exact phrasing.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class=""><br>
> +Use ``auto`` Type Deduction to Make Code More Readable<br>
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^<br>
> +<br>
> +Some are advocating a policy of "almost always ``auto``" in C++11, however LLVM<br>
> +uses a more moderate stance. Use ``auto`` if and only if it makes the code more<br>
> +readable or easier to maintain. Don't "almost always" use ``auto``, but do use<br>
> +``auto`` with initializers like ``cast<Foo>(...)`` or other places where the<br>
> +type is already obvious and clear.<br>
<br>
</div>How about making the recommendation be based on whether the expected type is obvious from context (e.g. dyn_cast/cast), or where the explicitly written type would have been abstracted anyway (std::vector<T>::iterator)?<br>
</blockquote><div><br></div><div>Done (prior to submitting).</div></div></div></div>