Generalize requirements for ?? and ?. operators to make them usable on custom types (via .HasValue(), .GetValueOrDefault() detection)

[T-Gro]

The built-in null coalescing ?? and null propagation ?. operators enable succinct processing of data that is possibly absent.
The operators can be composed in a longer sequence and work both on System.Nullable<T> type as well as nullable reference types.

What is not possible at the moment is to use the two operators with custom containers representing possible absence of information.
The following examples come to mind:

• F#'s Option<> , ValueOption<> and Result<> types
• User defined Maybe types popular in functional-C# codebases https://github.com/search?q=Maybe+language%3AC%23&type=code
• User defined Optional types https://github.com/search?q=Optional%3CT%3E+language%3AC%23&type=code

The proposal is to expand the two operators to be based on a pattern detected on the left-hand side of the expression.
The needs would be defined by having instance/extension methods accessible in current scope with the following signature:
bool HasValue()
T GetValueOrDefault()

For handling ?. null propagation, a static property representing the "missing data" scenario is needed:
$containerType<T>.None. If one does not exist, null is used for reference types and default System.Nullable<T> is returned for value types.

Migration concerns:
If the left-hand side is a System.Nullable<T>, the current rules would apply, no changes.
If the left-hand side is a nullable reference type known to be maybe null or null-oblivious, , the current rules would apply, no changes (it would be handy for many of the above mentioned containers to combine a x != null && x.HasValue() together, but that could be a breaking change for existing code).

Only if the left-hand side is a non-nullable value type or a reference type known to be not null, the detection for HasValue() and GetValueOrDefault() would start.

[ufcpp]

#2020

[T-Gro]

This suggestion would make the requirements of #2020 possible, indeed. The linked suggestion suggests overloading, which isn't the same.

This suggestion tries to bring in pattern based feature detection, common in many newly added C# features, to the older ?? and ?. functionalities of lowering an operator.

[AmrAlSayed0]

or a reference type known to be not null

This means that nullability will affect code generation which is an explicit no-no when nullable reference types was introduced in C#.

[T-Gro]

Alternative would be to accept the break for scenarios where people already have a user-defined type meeting the criteria ;; and are applying ?? or ?. to it as of today already.

With accepting the break, the null-check and .HasValue() check could be combined together.

[sab39]

Or make it only work for value types, which would cover the most common Option and Maybe types (because in at least most cases, the existence of null achieves the same thing as Option for reference types), and avoid the potential of breaking existing code because it would only apply in situations that would currently be a compilation error.

[colejohnson66]

Related? dotnet/runtime#105923