87 lines
3.1 KiB
Markdown
87 lines
3.1 KiB
Markdown
# 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.
|
|
|
|
1. Constructors
|
|
2. Dotted names
|
|
3. Default expressions
|
|
4. Should we track null state for nonnullable ref types?
|
|
5. Inferred types for method type inference
|
|
6. Inferred nullability in hover tips
|
|
7. Smaller things not yet done
|
|
8. Unconstrained generics
|
|
9. 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.
|
|
|
|
``` c#
|
|
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?)
|
|
|