Change precedence of switch expression from relational to unary

[gafter]

The switch expression is currently specified to be at relational precedence. I propose to change it to be at primary precedence. See HERE for the precedence chart of existing operators.

The reason for this proposed change is that the switch expression behaves more similarly to postfix unary operators (which are primary expressions) than it does to any kind of binary operator. For example, it has one operand that appear to the left. The current situation is somewhat confusing, and I believe the proposed change will remove most confusion.

Issue 1: Confusing precedence inversion

With relational precedence, it is not legal to write

x = e switch {...} + 1; // syntax error today

Because this code attempts to write an addition in which the left operand is of higher precedence. The result is simply a syntax error. Fixing this requires awkwardly parenthesizing the whole switch expression:

x = (e switch {...}) + 1; // ok

It is difficult to explain this error (and fix) to the user, as the switch is obviously the left operand of the addition.

With primary precedence, the original code is legal and has the obvious intended meaning:

x = e switch {...} + 1; // proposed OK

Issue 2: Unclear operands

With relational precedence, it is not clear which is the operand to the switch expression:

x = a + b switch {...}; // what is the switch's left operand?
x = a & b switch {...}; // what is the switch's left operand?

The answer is that the left operand is a + b today on the first line, but b on the second line. If you wanted the operand to be only b in the first line, you would have to awkwardly parenthesize the entire switch expression.

With primary precedence, the switch expression's operand is b for both lines. If you want the operand to be a + b or a & b, you can simply parenthesize that operand. That will feel natural to users, who may even expect the switch expression's operand to always be parenthesized as a matter of style.

Issue 3: primary vs unary

Why do I propose primary rather than unary precedence? There are pros and cons of primary compared to unary.

One pro is that is would be possible to index (or invoke, or dot off of) the result without a confusing syntax error:

x = e switch { ... }[i];
x = e switch { ... }(e);
x = e switch { ... }.P;

If the switch expression were at unary precedence, these would be difficult to explain syntax errors (unexpected token [, (, or .).

One con is that the left operand cannot be subject to a unary operator:

x = -e switch {...};
x = (T)e switch {...};

At primary precedence, the negation or cast operator applies to the whole switch expression. At unary precedence, the negation or cast applies only to e, the operand of the switch expression. I do not know which is more "natural". I suppose I could be convinced that unary precedence is better than primary.

[YairHalberstadt]

My personal feedback is that

x = e switch { ... }[i];

Feels like it's to 'big' an expression to want to index into. I.e. it feels like bad code style to want to do this anyway.

Whereas

x = -e switch {...};
x = (T)e switch {...};

Feel like things I would very much want to write, and I would expect to have the behaviour where we switch on -e or (T)e.

On the other hand, it's probably easier to put -e in parentheses than it is to put the entire switch expression. However that obviously depends on the length of the expression.

This all just personal feedback, and I would be happy with either.

[CyrusNajmabadi]

I suppose I could be convinced that unary precedence is better than primary.

Personally, unary feels more correct for me. Here's a somewhat handwavy reason why:

the primary exprs are the ones that have traditionally been 'so tight' that we don't even bother putting spaces between things when we write them. We consider them "one big chunk" that shouldn't be broken up by something else. This is also true for 'unary' exprs. i.e. 'casts' are written as (A)b not (A) b. The same for +a, -a, a++, etc. These are thought of as a full element that stays together.

switch is not in that category. Because it's a word, it must have a space following the expressoin, and as such, will always look like expr switch. As such, it automatically feels less tight than the unary/primary bits of expr. So it would feel unintuitive if it now bound more tightly than the piece of syntax that was actually compactly written as part of the switch to the user.

i.e.

-e switch ...

That intuitively feels like it is:

(-e) switch not

-(e switch)

[yaakov-h]

How would precedence work with await e switch?

[CyrusNajmabadi]

How would precedence work with await e switch?

To me, that would be akin to writing: await e++ (which is legal). So it should be await (e switch ...).

I also think that is intuitive enough for me. If you are really wanting to do the above, needing to parenthesize into (await e) switch to make things clear is fine with me.

[gafter]

All of the unary operators are prefix operators today. So there is no need for associativity. Once you add a postfix operator to the unary operators, there is an associativity issue. await e switch is just such an issue. It is not akin to await e++ because e++ is a primary expression (not a unary expression) and therefore binds more tightly.

So if we go with unary, we'd have to decide on associativity as well.

I could be convinced either way on the desired associativity.

[CyrusNajmabadi]

All of the unary operators are prefix operators today.

My mistake. I thought postfix-expressoin was in the unary-category. It does not help that we call them PostfixUnaryExpression in our syntax model :)

[Thaina]

As for me I think we would be more likely to

e switch {
    conditionA => await SomeThing(),
}

Than

await e switch {
    conditionA => SomeThing(),
}

And for negative we could just

(-e) switch { ... }

While

e switch {
    // return same type in difference condition
}.Some.Deep.And.Long.Named.Member;

Is more useful

[yaakov-h]

At first I was thinking that await should apply to the result of switch.

The more I think about it, awaiting inside the switch makes far more sense than awaiting the result of the switch in most cases.

Switching the result of an await also seems desirable, so I'd think await e switch should act like (await e) switch and not await (e switch...).

[BillWagner]

moving to dotnet/csharpstandard

[gafter]

We ended up settling on unary precedence.

[FreeApophis]

As discussed here, the same irregularities apply to the with operator. with is inheriting the precedence from switch and it behaves the same way. The additional paranthesis seem odd, and the argument for switch do not hold anymore for simple with expressions which are usually a one-liner.

What is additionally strange due to the with expressions, is the glazing difference to the object initializer:

While this works:

var fromInitializer = new ComplexNumber { Im = 3 }.R;

This does not:

var fromWithExpression = zero with { Im = 3 }.R;

I am aware after the discussion, that this due to operator precence between with and ., and the object intializer is an integral part to the object constructor. However the intent is very similar, you initialize the object and I think it is a natural to assume it behaves similar.