Analyze tuple conversions element-wise with W-warnings

[jcouv]

Currently, we treat tuples like generic Pair<T1, T2> during the conversion/assignment. This results in a redundant safety warning, since we already track the initial state of Item1/Item2 in the case of tuples.

#nullable enable
public class UnitTest1
{
    void M(string? s, string s2)
    {
        (string, string) t = (s, s2); // should be W-warning on elements
        t.Item1.ToString();

        // Motivations to change this:
        // - redundant safety warning
        // - generic type inference
        // - deconstruction

        Pair<string, string> p = Pair.Create(s, s2);
        p.Item1.ToString();

        var t2 = ((string, string))(s, s2); // should be W-warning on elements. t2 is (string, string), but state is Item1 is nullable 
        t2.Item1.ToString(); // safety
    }
}
public class Pair<T1, T2>
{
    public T1 Item1;
    public T2 Item2;
}
static class Pair
{
    public static Pair<T1, T2> Create<T1, T2>(T1 x, T2 y) { throw null; }
}

FYI @cston

[jcouv]

Closing from discussion with the team.

We’ve explored the tuple scenario in more details with the crew and we still feel the current behavior is correct.
In short, I’m happy to close this issue without further discussion in LDM.

For the record, the alternative was clarified as (roughly): whenever you read a local of tuple type, we would give the result a type based on the state of the tuple.

But this involves complexity:

• We would do this for tuples in locals, but probably not those nested in other types.
• We’d have to do special checks for passing tuples as ref arguments.

And the benefits aren’t clear:

• Users probably don’t expect to see the type of a tuple local change as they do for simple locals.
• Inferring (string?, string) in the scenario below doesn’t seem a major advantage.