C# Language Design Notes for Nov 8, 2017

Agenda

We went over the status of the prototype for nullable reference types, to address outstanding questions and make any last minute calls before release.

Constructors
Dotted names
Default expressions
Should we track null state for nonnullable ref types?
Inferred types for method type inference
Inferred nullability in hover tips
Smaller things not yet done
Unconstrained generics
Other issues

Constructors

Currently the prototype warns on a constructor that doesn't directly initialize all fields, even if it has a this(...) constructor initializer. It should exempt such constructors completely, since it will have required the called constructors to fully initialize.

We may consider a more nifty analysis than that later, at least for private constructors, but it doesn't seem high priority for the prototype.

It's a warning per constructor. If it's on the implicit (default) constructor it goes on the class name. That's good.

We don't warn for the default constructor on structs. It's not really actionable, we think, since people can't write their own default constructor or add initializers to fields of structs. But this is worth revisiting later, probably in the context of Xtreme mode.

Dotted names

Now work in the prototype, modulo a few bugs. (Not fully handling reassignment).

Default expressions

Should default(string) be of type string? or should it yield a warning in and of itself, and be of the type string (the type it states).

This is a question that's related to whether string s = null as a local declaration yields a warning.

We're going to leave the current implementation, which makes default(string) be a string?.

Similar with (string)null. It's type is string?.

Should we track null state for nonnullable ref types?

Not now. Worth thinking about for later, as a stop gap.

Inferred types for method type inference

In the current implementation, the best common type and method type inference don't pick up inferred nullability, but only declared nullability.

void M(string? s)
{
    if (s == null) return;
    var a = new[] { s }; // string?[], should be string[]
}

We can live with that as a known issue in the prototype.

Inferred nullability in hover tips

Currently shows declared nullability. Relatively big work item, won't be fixed in prototype. So we need to set expectations.

Smaller things not yet done

Some warnings not given. That's alright, we'll give more in the future. New constraints (class?, object) aren't added. That's not blocking. Variance: we'll deal with it when we get there.

Unconstrained generics

Need to revisit to see if the weirdness we do is the right weirdness. Based on design review feedback, it is ok if what we do is not consistent with the rest of the language; the higher order bit is that it is helpful, intuitive and not obnoxious.

Other issues

No switch in the prototype; warnings are always on. We need to design the command line switch.
Annotations for TryGet etc. still need to be designed.
How to update BCL with annotations. (Automatically?)

3.1 KiB Raw Permalink Blame History