Nullness bug when casting a string to an interface

[charlesroddie]

let t1 = "" :> IEquatable<string>
// Nullness warning: A non-nullable 'string' was expected but this expression is nullable. Consider either changing the target to also be nullable, or use pattern matching to safely handle the null case of this expression.

VS 17.14.6

Misc notes:

• The IEquatable interface unfortunately marks arguments to Equals as nullable generic mathematics interfaces should use nullable reference types runtime#73855 (comment), a wart which F# seems to squash, allowing IEquatable<'T> to be defined with Equals(y: 'T) = .... But that doesn't seem directly relevant to the above issue.
• "" :> IEquatable<string | null> doesn't give a warning
• A workaround is to define a wrapper [<Struct>] type StringWrapper(s: string) = member _.Value = s.
• This applies to types where null is "allowed":

[<AllowNullLiteral>]
type NullAllowed() =
    interface IEquatable<NullAllowed> with member _.Equals(y: NullAllowed) = true
let _ = NullAllowed() :> IEquatable<NullAllowed>
// Nullness warning: The types 'IEquatable<NullStringWrapper>' and 'IEquatable<NullStringWrapper> | null' do not have compatible nullability.

[T-Gro]

This is the likely issue - https://github.com/dotnet/runtime/blob/main/src/libraries/System.Private.CoreLib/src/System/String.cs#L32
String implements IEquatable<string?>, and not IEquatable<string> .

The interface is not marked as being contravariant, and the compiler does not know how the T param is used.
(nullness does piggyback on the in T markers used for generics to figure out if a T | null type instantiation of a generic interface can consume plain T or not)

[T-Gro]

Ok I hate this dotnet/roslyn#37187 and how it was fixed for C#, but then I also do not see any better option right now.

In the generic case, we cannot do it - since we do not know how a generic interface works with its T internally.
At the same time, I do get why IEquatable is not marked as in T when e.g. IComparable is - it could falsely report derived types as being equal to the base.

[charlesroddie]

Thanks for taking this up @T-Gro . string implements IEquatable<string?> (despite claiming in the docs to implement IEquatable<string>) which then would be supposed to implement Equals(string??) and something (a spellchecker?) reduces that to Equals(string?)??? It's above my head but... it's nonsense surely?

Also did copilot write that PR by itself?

[T-Gro]

It think it fits to the nonsense = cascade of historical (20+y?) decisions coming together category.
It learns one to appreciate how much better optionality via the type system (Option<T>) can be compared to the flood of special cases coming together in Nullability.

Copilot wrote that PR after a deeper interactive chat with me - I had to point it in which direction to go and which files to look for, and only asked it to raise that PR after the important context was in the chat. It works a lot better then simply giving it the original issue as-is.