carbon-lang/proposals/p0623.md

Require braces

Pull request

Table of contents

• Problem
• Background
  • Consistency
  • C++ style rules
  • goto fail
• Proposal
• Rationale based on Carbon's goals
• Alternatives considered
  • Optional braces
  • Optional parentheses
  • elif

Problem

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?

Background

Consistency

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#.

C++ style rules

There is a CERT rule for when to use braces.

goto fail

Apple had an infamous goto fail bug:

• https://www.imperialviolet.org/2014/02/22/applebug.html
• https://dwheeler.com/essays/apple-goto-fail.html

Proposal

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 (...) { ... } }.

Rationale based on Carbon's goals

• 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.

Alternatives considered

Optional braces

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 unclear else bindings. For example:

    if (x)
    if (y)
      DoIfY();
    else
      DoIfNotY();
    else
      DoIfNotX();
    

  • If Carbon were to reuse if and else 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.

Optional parentheses

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 ().
• 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.

elif

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.