Consider adding MaybeDefault to Microsoft.CodeAnalysis.NullableFlowState

[cston]

Consider adding MaybeDefault to Microsoft.CodeAnalysis.NullableFlowState to allow analyzers to differentiate values that may be null even if the type may be not nullable.

For instance, to represent the flow state of item:

static void M<T>(List<T> list)
{
    T item =  list.FirstOrDefault();
    // ...
}

See dotnet/csharplang#2946
See #39778

[jcouv: even if we don't make this change, we should document the maybe-default state in Mads' spec]

[cston]

cc @jasonmalinowski, @333fred

[sharwell]

This would be a huge help for ImmutableArray<T>, where default behaves more like null than new T[0]. Most of the flow tracking would work great with existing attributes. The only part that can't be easily represented today is indicating that a field of one of these types is not allowed to have a default value (can't reuse the ? syntax because it means Nullable<T> for value types).

Related to dotnet/csharplang#146
Related to dotnet/csharplang#2840 (comment)

[333fred]

@sharwell I don't think this helps at all for ImmutableArray<T>. I think you're misconstruing from the naming here. MaybeDefault applies to unconstrained type parameters, not to value types. We're not planning on extending tracking whether or not a known struct type is defaulted or not.

[sharwell]

In that case, how would MaybeDefault help? MaybeNull already has the same meaning in that case.

[333fred]

It does not. This is how we've solved the [MaybeNull] on unconstrained type parameters, it's very possible some IDE features will want to see this info as well.

[Joe4evr]

@sharwell

The only part that can't be easily represented today is indicating that a field of one of these types is not allowed to have a default value

I've said before, it might be the most practical to let that be a documented caveat when the default-ness is a private implementation detail. It's primarily the places where the default-ness can escape over an API boundary where the flow analysis should inform the consuming code.

[jaredpar]

Closing as this would represent a breaking change at this point, particularly since we added the defaultable generic support to nullability. Can re-open and re-visit a different style of API if we get enough requests for it.