This program generates compiler warning CS8620
Argument of type 'IEnumerable<(string S1, string S2)>' cannot be used for parameter 'e' of type 'IEnumerable<(string? s1, string? s2)>' in 'void Program.F(IEnumerable<(string? s1, string? s2)> e)' due to differences in the nullability of reference types.
But I'm not trying to pass off something that can be null as something that can't, I'm doing the opposite! That should be perfectly fine!
Is there some way I can tell the compiler, "look I know it can't be null, just pretend that it can be"? An opposite to the null-forgiving operator? A null-condemning operator?!
namespace MyNamespace;
public static class Program
{
public static void Main(string[] args)
{
var L = new [] {new C("S1", "S2")};
F(L);
}
public class C
{
public string S1 { get; }
public string S2 { get; }
public C(string s1, string s2)
{
S1 = s1;
S2 = s2;
}
}
public static void F(IEnumerable<C> e)
=> F(e.Select(c => (c.S1, c.S2)));
public static void F(IEnumerable<(string? s1, string? s2)> e)
{}
}
It would be fine if the original collection cannot be modified through the IEnumerable .. but it can be. Consider this code, which yes, is a bit of a hack, that's the point:
Lis an array of tuples of regular strings (notstring?). The body of theifinFis executed, and a null ends up in that tuple anyway. So the compiler warning about that call toFis not wrong.