In C++, braces are often optional, such as in:
for (Shape x : shapes)
Draw(x);
Carbon adopted this design choice by default in proposals #285, #340, and #353. But should we keep it?
We were adopting the C++ syntax primarily for easy consistency with C++. For other languages:
- Some modern languages require braces, including Go, Rust, and Swift. Note some which require braces make parentheses optional.
- Kotlin is an example modern language which does not require braces.
- Older languages tend to make braces optional, including Java, JavaScript, and C#.
There is a CERT rule for when to use braces.
Apple had an infamous goto fail
bug:
- https://www.imperialviolet.org/2014/02/22/applebug.html
- https://dwheeler.com/essays/apple-goto-fail.html
Carbon should require braces when they might otherwise be optional. We should
continue to require parentheses. This currently comes up in if
/else
,
while
, and for
.
We will allow else if
as a special structure for repeated if
statements due
to their frequency. For example, if (...) { ... } else if (...) { ... }
behaves identically to if (...) { ... } else { if (...) { ... } }
.
-
Software and language evolution: Reducing parsing ambiguity of curly braces is important for expanding the syntactic options for Carbon.
-
Code that is easy to read, understand, and write: We have a preference to give only one way to do things, and optional braces are inconsistent with that. It's also easier to understand and parse code that uses braces, and defends against the possibility of
goto fail
-style bugs, whether accidental or malicious. -
Interoperability with and migration from existing C++ code: While C++ does make braces optional in related situations, we believe this isn't fundamental to migration or familiarity for C++ developers, so this goal is not meaningfully impacted by this change.
We could instead keep braces optional, such as:
if (x)
return y;
Advantages:
- Consistent with C++.
- Allows for greater brevity in code, such as
if (!success) return error;
.
Disadvantages:
-
Gives two ways of doing the same thing.
- Style guides will make choices, creating more contextual coding style.
- Some community members opined that requiring braces was the only
solution which is both appealing and easy to automate formatting for.
- A contrary opinion is that single-line if statements without braces are more appealing, and not significantly more difficult to automate.
-
More complex and harder to parse.
-
Nested
if
statements can have unclearelse
bindings. For example:if (x) if (y) DoIfY(); else DoIfNotY(); else DoIfNotX();
-
If Carbon were to reuse
if
andelse
keywords for a ternary operator, that could omit braces in order to avoid ambiguity. For example,int x = if y then 3 else 7;
.
-
-
Developers are known to make mistakes adding statements to conditionals missing braces, keeping consistent indentation, and missing the incorrect behavior due to cognitive load. For example:
if (x) return y;
->
if (x) print("Returning y"); return y;
- Developers commonly want to add debugging statements to conditionals, and missing braces can lead to these kinds of errors.
- It's possible that, over time, adding braces to add debug statements
then removing the debug statements without removing statements will lead
to braces remaining when braces are optional.
- This can be addressed by style guides and automated formatting that inserts or removes braces as appropriate, cleaning up after temporary edits.
- Some people feel the churn of adding braces and later removing them is a significant toil that can be avoided by always adding them, such as here.
- It can more easily lead to bugs like
goto fail;
.- However, as the blog post points out, one can have incorrect indentation with braces too.
Languages which make braces required can make parentheses optional, or even disallow them, such as:
if x {
return y;
}
Advantages:
- Exchanges verbosity in syntax, requiring
{}
but removing()
.- Particularly useful in that many conditionals have
{}
regardless of optionality, but all conditionals could in theory remove()
.
- Particularly useful in that many conditionals have
- Cross-language consistency with languages that require
{}
.
Disadvantages:
- Visual inconsistency with C++.
- Parentheses make parsing less likely to encounter ambiguity.
- Optional parentheses lead to two ways of doing the same thing, although disallowing them entirely could address this.
We could make else if
a single token, such as elseif
or elif
.
Advantages:
- Can parse as a single token.
Disadvantages:
- Visual inconsistency with C++.
else if
also appears in some languages that require braces, such as Go, Rust, and Swift.