Change operator precedence

Pull request

Table of contents

Abstract

Update the operator precedence to achieve a few goals:

  • Form operators into groups which behave similarly
  • Make the group of operators (“top-level operators”) that capture everything to the right, like if…then…else, behave similarly to the left, so that rearranging expressions won’t change how they group.
  • Add the where operator, used to specify constraints on facet types, to the precedence chart, to define how it interacts with other operators.
  • Make the operator precedence diagram prettier, so that it eventually can be made into a poster that Carbon programmers can hang on their walls.

Problem

The where operator is particularly tricky:

  • It is used in an impl declaration to specify the values of associated constants (such as associated types). In that context, impl T as I where R is interpreted conceptually as impl T as (I where R). It would be nice if T as I where R would mean the same thing in other contexts. If not, we’d rather it to be invalid rather than meaning (T as I) where R. That is, That is, considered in isolation, we would prefer T as (I where R) over invalid over (T as I) where R.
  • The where operator will frequently be used with the binary & operator, since that is how facet types are combined. It is desirable that I & J where R be interpreted as (I & J) where R. If not, we’d rather it be invalid than be interpreted as I & (J where R). This usage of & with where is expected to be more common than combining where and as outside of an impl declaration.
  • The “restriction” on the right side of a where uses operators that mean something else in an expression context: and, ==, =. We would like to minimize the confusion when both kinds of uses of those operators appear in the same expression.

These goals are in conflict with the current precedence partial order.

Background

The initial operator precedence approach, including using a partial precedence ordering instead of a total ordering as found in most languages, was established by propsoal #555. PR #1070 established the current precedence chart, which has been incrementally added to since then.

Proposal

We are making a number of changes:

  • x as T is no longer allowed on either side of a comparison operator, or the short-circuiting operators and & or.
  • x where R is a peer to as, but its arguments can be binary operators (like &). This matches the comparison operators, which are either illegal or reinterpreted as an argument to where.
  • The type constructors T* and const T are no longer separate from the other unary operators, and can now be the argument of any binary operator.

Details

Please see the new precedence diagram in docs/design/expressions/README.md.

Rationale

Precedence is about Code that is easy to read, understand, and write. We don’t want to require parentheses too often since that makes the code harder to write, and if it goes too far even reading becomes difficult. However, we do want parentheses to mark code that would otherwise be misinterpreted. This is a balancing act we expect to have to refine with experience.

Alternatives considered

as and where could be peers of if…then…else

We considered making all the “top-level” operators act the same for precedence, but we expect users to want to use as to force the two branches of an if…then…else expression to a common type often enough, and we didn’t expect the result of doing that to be confusing to read.

Make T as I where R mean T as (I where R)

We wanted to make T as I where R mean the same facet type as that same sequence of tokens in an impl declaration. However, this was in conflict with the arguments to where being the same as the arguments to comparison operators. We didn’t want to allow an expression mixing binary operators with as since we expected users to expect that to mean performing the operation with that casted-to type. For example, x + y as i64 would mean (x + y) as i64, which would perform the addition and only then cast to i64, which is probably not what would be intended by that expression. We thought it better to make x + y as i64 illegal to force users to use parentheses, even if that meant also using parentheses with T as I where R in an expression context.

Make fewer changes

We considered making fewer changes to precedence, but that lead to an operator precedence diagram with crossing edges (it was non-planar). This was felt to be a sign that the graph was too complex, making it harder for humans to understand and remember. It was suggested that developers using Carbon may want to have the precedence graph posted for reference, and a planar graph would make a more-appealing poster.

This was discussed in open discussion on 2024-06-20.

Different where syntax

We considered other ways of marking the end of a where restriction expression, such as requiring parens (…) (either around the argument or the whole where expression) or having a keyword at the end. We ultimately decided none of those options were satisfactory since they added noise that reduced clarity, and decided to go with a greedy approach (“all the way to the right”) instead.

This was discussed in open discussion on 2024-06-13