<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p><br>
</p>
<div class="moz-cite-prefix">On 7/1/20 9:55 AM, Quentin Colombet via
llvm-dev wrote:<br>
</div>
<blockquote type="cite"
cite="mid:854CBDB4-D59B-4D9D-A664-50349C097516@apple.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
Hi,<br class="">
<div><br class="">
<blockquote type="cite" class="">
<div class="">On Jul 1, 2020, at 6:23 AM, James Henderson via
llvm-dev <<a href="mailto:llvm-dev@lists.llvm.org"
class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div dir="ltr" class="">
<div class="">At the very least, I accept clarifying the
wording to make it clear where braces should/shouldn't
be used. I personally would still prefer a general
"always add braces in new code" rule,</div>
</div>
</div>
</blockquote>
<div><br class="">
</div>
<div>FWIW, +1 on always using braces.</div>
<div>I like having more compact code without the braces but at
the same time, LLVM is the only code base that I work on that
doesn’t always have braces. Thus, the benefits are not worth
the mental gymnastic for me.</div>
<div><br class="">
</div>
<div>I am not saying we should update all the code but I think
going forward we could adopt this rule and eventually all the
code will migrate.</div>
</div>
</blockquote>
<p>(Meta point)</p>
<p>This thread has mixed a large number of proposed changes. I have
lost track completely. I'm about to stop reading this thread, and
ask that if there is a consensus reached that a separate RFC is
sent the list for broader review. This might even be a good trial
run for Chris's new controversial proposal process.</p>
<p>Philip<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:854CBDB4-D59B-4D9D-A664-50349C097516@apple.com">
<div>
<div><br class="">
</div>
<div>Cheers,</div>
<div>-Quentin</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class=""> given that I literally just ran into
another case where a code change I made locally caused
test failures because I'd forgotten to add the braces on
a previously single-line if, although in this case, it
should have had braces already, since it had a comment
between the if and statement within the if.
clang-formatting would have pointed out the error, had I
run it, but I hadn't done so. Total cost to me was 2-3
minutes trying to figure out what was wrong. A rule of
"always braces" would have meant those 2-3 minutes could
have been spent on other things.<br class="">
</div>
</div>
<br class="">
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Tue, 30 Jun 2020 at
20:59, Chris Lattner via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
wrote:<br class="">
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex"><br class="">
<br class="">
> On Jun 29, 2020, at 8:05 AM, David Greene <<a
href="mailto:david.greene@hpe.com" target="_blank"
class="" moz-do-not-send="true">david.greene@hpe.com</a>>
wrote:<br class="">
> <br class="">
> Chris Lattner via llvm-dev <<a
href="mailto:llvm-dev@lists.llvm.org" target="_blank"
class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a>>
writes:<br class="">
> <br class="">
>> For those who don’t like it, is the currently
documented policy broken<br class="">
>> enough to be important to changing?<br class="">
> <br class="">
> I believe it is, simply for safety reasons. Adding
a statement to a<br class="">
> single-statement block can introduce bugs.
Mandating braces everywhere<br class="">
> prevents that.<br class="">
<br class="">
Sure, I get that. For background, the Swift language
(which I was highly involved in) mandates braces - I’m
just saying that I'm aware of the benefits and tradeoffs
here. In addition to the “safety” advantages, there are
balancing cognitive disadvantages to requiring braces
(less code fits on one screen, etc). These are all well
understood effects.<br class="">
<br class="">
That said, this is not a new project, and many of the
benefits fall below the line of being “worth it” given a
large and established codebase. I don’t see a strong
reason to change the policy here, though I think we
should give more guidance and clarify the wording!<br
class="">
<br class="">
-Chris<br class="">
<br class="">
_______________________________________________<br
class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" target="_blank"
class="" moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br
class="">
<a
href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev"
rel="noreferrer" target="_blank" class=""
moz-do-not-send="true">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</blockquote>
</div>
_______________________________________________<br class="">
LLVM Developers mailing list<br class="">
<a href="mailto:llvm-dev@lists.llvm.org" class=""
moz-do-not-send="true">llvm-dev@lists.llvm.org</a><br
class="">
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a><br
class="">
</div>
</blockquote>
</div>
<br class="">
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
LLVM Developers mailing list
<a class="moz-txt-link-abbreviated" href="mailto:llvm-dev@lists.llvm.org">llvm-dev@lists.llvm.org</a>
<a class="moz-txt-link-freetext" href="https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev">https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev</a>
</pre>
</blockquote>
</body>
</html>