Proposal: Patterns for "as" to treat "unmatched" as null

[IS4Code]

Note: There was another proposal (#402) using x as T y, but with different semantics (and disjoint syntax),

Motivation

A lot of the language is built around pattern matching and option-like null propagation or guards (?. and ??), yet these two systems don't go that well together. For example:

Class(string? a, string? b)
{
    this.a = a != null ? a : "<unspecified>";
    if(b == null) throw new ArgumentNullException(nameof(b));
    this.b = b;

    // can be easily simplified as

    this.a = a ?? "<unspecified>";
    this.b = b ?? throw new ArgumentNullException(nameof(b));
}

Yet in situations where null is not the only "exceptional" value, there is no syntax to simplify to:

Class(string? a, int b)
{
    this.a = a is not null or "" ? a : "<unspecified>";
    if(b < 0) throw new ArgumentOutOfRangeException(nameof(b));
    this.b = b;
    // both "a" and "b" need to be referenced twice
}

In many situations, there are special values outside of null that need to be checked ‒ empty strings or collections, 0, -1, or SomeEnum.None, or objects containing these, but there is no easy way of discarding these values other than using conditions.

What if we were instead able to leverage the existing null-centered syntax to "coerce" the unwanted values to be null? Is there any piece of syntax with the meaning "make sure this is X, otherwise be null"? Actually, yes ‒ as!

Extending patterns for as

This proposal aims to extend as consistently with its original relation to is to support (non-assigning) patterns. Roughly speaking:

x as P

would be more or less equivalent to

x is P y ? y : null

This is a natural extension for the original syntax x as T, now reinterpreted as x is T y ? y : null. The operation corresponds to "match x to P, or produce null if unmatched".

Concretely, this would parallel is in the following situations:

is syntax	is semantics	as syntax	as semantics
x is T	type check	x as T	unchanged (cast to T?, or null on failure)
x is T { ... }	type and properties check	x as T { ... }	cast to T?, ensuring the properties, or null on failure
x is { ... }	properties check	x as { ... }	cast to the nullable equivalent of the type of x, ensuring the properties, or null on failure
x is T and P	type and P check	x as T and P	cast to T? (or a more specific applicable type from P), ensuring P, or null on failure
x is P	P check	x as P	cast to the nullable equivalent of the type of x (or a more specific applicable type from P), ensuring P, or null on failure

The pattern may not create any new variables (since otherwise their use would require the check that the result is not null).

Examples

object? o;
string s;
byte b;

• s as { Length: > 10 } ‒ results in s if s is { Length: > 10 }, or null (type string?).
• o as >= 0 ‒ results in a value of type int? as either >= 0 or null.
• b as not 0 ‒ results in a value of type byte? with the value of b if non-0, or null.
• o as not null ‒ just equivalent to o.

Uses

The code above could be easily simplified to:

Class(string? a, int b)
{
    this.a = a as not "" ?? "<unspecified>";
    this.b = b as >= 0 ?? throw new ArgumentOutOfRangeException(nameof(b));
}

Further examples

• (timeout as not 0) ?? DefaultTimeout ‒ treat 0 as unspecified timeout. Can be read as "timeout as not 0, otherwise DefaultTimeout".
• (myEnumValue as not MyEnum.Unspecified) ?? DefaultMyEnumValue ‒ same for an enum value:
• numerator / (denominator as not 0) ‒ null if division would cause a black hole.
• (collection as not [])?[0] ‒ access first element if there is one.
• (entity as { Exists: true })?.Property ‒ access entity only if it still exists, otherwise null.
• stream.ReadByte() as not -1 ‒ useful even alone so that you don't mistakenly use an invalid byte.
• IndexOf(...) as not -1 ‒ likewise.
• obj as not null ‒ not useful much, just results in obj (but makes the type nullable). Could be a warning.

Alternatives

An alternative syntax has been proposed, not depending on as, with a similar effect:

Class(string? a, int b)
{
    this.a = a when not "" else "<unspecified>";
    this.b = b when >= 0 else throw new ArgumentOutOfRangeException(nameof(b));
}

[KennethHoff]

I've seen many suggestions on this repository on how to improve upon this general area, and they're often way too niche and with arcane symbols.

This suggestion on the other hand - after reading it twice over, because I didn't fully understand what you were proposing the first time (compared to what already exists) - would fit into the language perfectly I think, as a natural evolution of the as keyword (being clearly connected to the is keyword)

[HaloFour]

I'm conflicted. I think the syntax is fine, but it's such a minor improvement to the current syntax using the conditional operator or switch expressions that I don't think that the implicit result of null in the failing case is worth it. That's especially true when paired with ??. I also don't care for the treatment of value types., especially since as doesn't work with value types at all today and I wouldn't particularly care to see it work.

Personally, I'd rather see syntax for expressing an unconditional pattern-based destructuring than another way of doing conditional pattern matching.

[IS4Code]

I understand, though I have seen a few situation where I really wished I could "coalesce" something other than null, which is why I care about value types here too. Cases like Stream.ReadByte() returning -1 are not so common nowadays, but I still encounter them (well actually IndexOf is another example).

[333fred]

I think I'm willing to champion this proposal, if for no other reason than to bring to LDM and get an initial gut check on it. @IS4Code, could you please open an issue with your proposal? The initial check doesn't need to be any more detailed than what you have here; if the LDM thinks there's something we'd be willing to see in the language here, we'd then need to expand out to a full proposal.

[IS4Code]

Proposed as #8210. Please let me know if I can include more details. 👍

[jnm2]

I would prefer when or if.

Class(string? a, int b)
{
    this.a = a when not "" else "<unspecified>";
    this.b = b when >= 0 else new ArgumentOutOfRangeException(nameof(b));
}

[thomhurst]

I would prefer when or if.

Class(string? a, int b)
{
    this.a = a when not "" else "<unspecified>";
    this.b = b when >= 0 else new ArgumentOutOfRangeException(nameof(b));
}

This feels quite kotlin-y - Which isn't a bad thing.

[MgSam]

Definitely should be ‘when’ given the prior art in the language of exception filters and switch filters using ‘when’ for postfix conditions.

[kanpov]

This feels quite kotlin-y - Which isn't a bad thing.

C# should be moving towards kotlin imo, and pretty much already is