Proposal: Allow nullable types in declaration patterns

[alrz]

Allow nullable types in declaration patterns

• Proposed
• Prototype: Not Started
• Implementation: Not Started
• Specification: Not Started

Summary

Allows the type to be specified in a var-pattern without change in semantics. This was originally proposed at #2039 but discarded due to possible behavioral change (see #2039 (comment) for an example).

Motivation

Currently, specifying the type in patterns has the side effect of checking for null which may not be the intent. Using nullable annotation would allow the type to be specified for readability without the added null check.

Detailed design

This would be only allowed if the type has an identity conversion to the input type, therefore, preserving the var-pattern semantics. The added restriction would make this mostly a code style preference and a safe replacement for var-pattern.

bool M(object o) => o is int? x;     // error
bool M(int? o) => o is int? x;       // ok - same as `o is var x`
bool M(string? o) => o is string? x; // ok - same as `o is var x`

Note that the input type may not be immediately obvious, for example in a property pattern: { Prop: string? str }.

If the original input is already in a not-null state, a nullable type syntax will drop the null check which is currently emitted regardless of type annotations on the input type. However, in this case, the variable would still have the not-null state, as it is the case for a var-pattern in the same situation.

Unresolved questions

• Would it be safe to allow implicit reference conversions as well?
• What is the expected behavior in null-oblivious context for value and reference types? Could we allow one but not the other?

Design meetings

None.

[CyrusNajmabadi]

Initial issue i see is the complexity of disambiguating this versus a ternary expression.

[alrz]

Yeah, that's going to be too complicated. Though I think we could require parens around the pattern or the expression if we can't immediately disambiguate which should be rare.

[333fred]

LDM looked at this on 5/19. There are some really gnarly parsing ambiguities here, but even if we could solve the compiler parsing problem, the human parsing problem will remain. We don't think those problems are really solveable, and that the gain isn't worth the complexity.

[jcouv]

Another important point that was raised in the discussion: part of the design for the nullability feature is that annotations do not affect code semantics. But here the ? annotation on the type would affect whether a null check is emitted.

[HaloFour]

@jcouv

Another important point that was raised in the discussion: part of the design for the nullability feature is that annotations do not affect code semantics.

Was that intended to permanently be the case? That would preclude combining them with new features or in new ways where they could affect the code semantics in useful ways.

[jcouv]

@HaloFour It's hard to tell until we've found an example where we want to break that rule. My understanding is likely yes (permanently) because we'll always have people that are using the latest version of C# without nullability enabled who later decide to annotate. So that concern will remain valid for new features even though nullability shipped a while back...