C# Language Design Notes for Feb 28, 2018

Warning: These are raw notes, and still need to be cleaned up. Read at your own peril!

Parameters: Value parameters can be treated like locals, but we may not want to. Ref and out parameters need to be guarded by non-W warnings.

Is it a problem that this can lead to two related warnings? Maybe a little bit, but it's actually mostly good. You can address the declaration of s2 in three different ways:

• Make ns non-null before assigning
• Put a question mark on s2
• Turn of W warnings Would be weird if that last one introduced another warning!

Type inference:

We could have var always have ?.

    static T[] MakeStack<T>(T element)
    {

    }
    static int GetLengthOfMiddleName(Person p)
    {
        string? middleName = p.MiddleName;

        //return middleName.Length;
        if (middleName is null) return 0;
        var stack = MakeStack(middleName); // infer string[] or string?[]
    }


        bool b = false;
        string s = null; // suppressible
        var s2 =
            //(b ? s : s);
            Choose(b, s, s);
        var l = s2.Length; // not suppressible

Should we have type inference depend on the declared or the flowed type state? We reiterated that discussion, but conclude (again) that it's the null state that counts. This maximally helps avoid unnecessary warnings on legacy code.

Cast and non-null

var s1 = "Hello"; // But I want to assign null later
var s2 = (string?)"Hello"; // Either disallowed, makes no difference or forgets null state
var? s3 = "Hello"; // Nullable but keeps the null state

So var? would be more useful than casts for var scenarios (because you are declaring a variable whose null state matters later). For generic arguments it doesn't matter to keep the flow state, so (string?) cast works fine.

It's a little weird that s2 and s3 don't work quite the same way. They do today.

Still, as a plan of record let's do this.

So we keep the casts, and tentatively keep var?.