meetings/2017/LDM-2017-11-08.md
We went over the status of the prototype for nullable reference types, to address outstanding questions and make any last minute calls before release.
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.
Now work in the prototype, modulo a few bugs. (Not fully handling reassignment).
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?.
Not now. Worth thinking about for later, as a stop gap.
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.
Currently shows declared nullability. Relatively big work item, won't be fixed in prototype. So we need to set expectations.
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.
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.