Determine whether the specification describes target-typed switch expressions

[Nigel-Ecma]

This specification does not describe target-typed switch expressions. See
dotnet/csharplang#2389
https://github.com/dotnet/csharplang/blob/main/proposals/csharp-8.0/patterns.md

The type of the switch_expression is the best common type (§12.6.3.15) of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type. In addition, we add a new switch expression conversion, which is a predefined implicit conversion from a switch expression to every type T for which there exists an implicit conversion from each arm's expression to T.

We have to be careful defining when the common type must exist (when there is no target type) and when it doesn't (the switch is target-typed). The spec must say that when there is no target type, it is an error if there is no common type.

Originally posted by @gafter in #873 (comment)

[jskeet]

We have this in expressions.md:

There is a switch expression conversion (§10.2.18) from a switch expression to a type T
if there is an implicit conversion from every switch_expression_arm_expression of each of the switch expression’s switch_expression_arms to T.

If a switch expression is not subject to a switch expression conversion, then

• The type of the switch_expression is the best common type §12.6.3.16) of the switch_expression_arm_expressions of the switch_expression_arms, if such a type exists, and each switch_expression_arm_expression can be implicitly converted to that type.
• It is an error if no such type exists.

I think that covers everything, but let's check in the next meeting.

[Nigel-Ecma]

@jskeet – I’m not sure it does, is when/how an expression is subject to a switch expression conversion clear?

In the simple assignment T x = ythe assignment is valid if there is an implicit conversion from the type of y to T (§12.32.2). Standard type calculation/infererence in C# is based solely on the types in the phrase being typed, so in this example the type of y does not depend on the type of x.

What is now being said is that if y is a switch expression (T x = switch …), then the type of y may depend on the type of x, indeed y may not have a single unique type at all unless the type of x is known. This is not unknown the universe of programming languages but it is an exception in C#.

The proposal referenced above (dotnet/csharplang#2389), which was later implemented, boils down to something like the following for checking T x = y:

1. Try to determine a single unique type for y
2. On success: check that type against T and pass/fail
3. On failure: try to unify the type expression for y with T and pass/fail

If this was, say, Haskell all type checking is based on unification and there is no need for a special case “switch expression conversion”. But it is C# where the text was written assuming no unification and in special cases where it is adopted it needs to be clearly specified.

[jskeet]

T x = y feels like the "simple" case to me. I'm worried about how overloading and generic type inference get involved :(

But yes, point taken about the details not being clear. I think the quoted bit is intended to cover target typing, but doesn't really. Will take another look... I do wonder whether it might work to treat switch expressions without a single unique type as "typeless" in the same way as null or anonymous functions. It may well crash and burn, but it'll be my next line of attack.

[jskeet]

In the simple assignment T x = y the assignment is valid if there is an implicit conversion from the type of y to T (§12.32.2).

(I'm assuming this was intended to be 12.23.2 rather than 12.32.2.)

The standard doesn't say "the type of y" - it just says y:

The type of a simple assignment x = y is the type of an assignment to x of y, which is recursively determined as follows:

• If x is classified as a variable, the variable is not readonly, x has a type T, and y has an implicit conversion to T, then the assignment has the type T.
• Otherwise, if x is classified as an implicitly typed variable (i.e. an implicitly typed declaration expression) and y has a type T, then the inferred type of the variable is T, and the assignment has the type T.
• Otherwise, if x is classified as a property or indexer access, the property or indexer has an accessible set accessor, x has a type T, and y has an implicit conversion to T, then the assignment has the type T.
• Otherwise the assignment is not valid and a binding-time error occurs.

It's really important that it's not "the type of y" otherwise this wouldn't compile:

string? x = null;

... because null doesn't have a type.

So as long as we're allowing an implicit conversion from an expression to a type rather than an implicit conversion from a type to a type, I suspect we're okay for the switch expression case.

I think we can change the part that I quoted before to say that a switch expression has a type in some cases, and doesn't have a type in others (but there's an implicit conversion from the expression in appropriate cases), and let the rest of the rules handle it.

I'll create a PR for that now as I think it'll be relatively straightforward - but I may have misunderstood your point.

[KalleOlaviNiemitalo]

Does something in the specification ensure that the switch expression conversion is not used for P.M1 below?

class B {}

class C1 : B {}

class C2 : B {}

struct S {
    public static implicit operator S(B _) => default;
    public static implicit operator S(C1 _) => default;
    public static implicit operator S(C2 _) => default;
}

class P {
    static S M1(int i) {
        // First converts from C1, C2, or B to the switch common type B, then from B to S.
        return i switch { 1 => new C1(), 2 => new C2(), _ => new B() };
    }

    static S M2(int i) {
        // Converts C1 or C2 directly to S.
        return i switch { 1 => new C1(), 2 => new C2(), _ => throw new System.ArgumentException() };
    }
}

A variant of the above, using enum types:

#nullable disable

using System;

enum E1 {}

enum E2 {}

struct S {
    public static implicit operator S(Enum _) => default;
    public static implicit operator S(E1 _) => default;
    public static implicit operator S(E2 _) => default;
}

class P {
    static S M1(int i) {
        // First converts from E1, E2, or Enum to the switch common type Enum, then from Enum to S.
        return i switch { 1 => new E1(), 2 => new E2(), _ => default(Enum) };
    }

    static S M2(int i) {
        // Converts E1 or E2 to S.
        return i switch { 1 => new E1(), 2 => new E2(), _ => throw new ArgumentException() };
    }
}

[jskeet]

@KalleOlaviNiemitalo I think in that case (using your first example), the switch expression in M1 would have a type (B) whereas the switch expression in M2 would not have a type (because there's no "best type").

I'd expect that to be enough to prevent the switch expression conversion from being used, but we probably need to chase that through. (We might want to merge #1734 first, close this, and create a new issue for that checking, which might not make the C# 8 cut, but we'll talk about it in the next meeting.)