Null Safety: Sound non-nullable types with incremental migration (NNBD)

[leafpetersen]

This is a solution proposal for #71. The proposal covers the intended final language design, and the language, tooling, and ecosystem support required for the migration.

• Roadmap
• Feature specification
• NNBD related issues

Topic specific discussion issues for resolution:

• Throw/catch static errors
• Null assertion operator
  • Resolved, yes, !.
• Should the NNBD opt in also remove implicit casts
  • Resolved, yes
• Is Object nullable?
  • Resolved, no
• Do we need T!?
  • Resolved, no
• Do we need generic constraints?
  • Resolved, no
• Grammar issues
• Fields initialized after creation
  • Resolved, we will use late
• Chaining null-aware operators
  • Resolved, yes.
• Default parameter values
• Can object methods be called on nullable types
  • Resolved, yes.
• Precedence of await vs !
  • Resolved, ! binds more tightly.
• Querying the state of late variables
• Null short-circuiting spread operator

[leafpetersen]

I've added a draft of the roadmap for this proposal, linked from the header comment.

[yjbanov]

@jmesserly I'm not sure how to constructively move the NNBD discussion from #125 here, because the my suggestion is all about linking the two issues. But I'll try:

I suggest that, as a first step, we introduce sound non-nullable types as part of immutable types (#125). This has several advantages:

• It would be a non-breaking change: immutable types is a new feature so having them NNBD doesn't break any existing code.
• It could have the biggest performance impact: if non-nullability is implemented such that many highly-used types can be inlined, such as double, int, bool, enum, String, we could significantly improve memory layout efficiency.
• It would give us a chance to get the syntax and semantics right and educate users before rolling NNBD to the "normal" classes, which does require a bigger migration.

[jmesserly]

IMO, linking the two proposals would be counterproductive. We are working hard on NNBD, there is a lot of design & planning work going on. There aren't any major open questions on syntax or desired semantics. Linking the two would prevent us from pushing forward on NNBD, because immutable types has a lot of open design questions, and we'd have to delay work on NNBD until that's resolved.

(Also it could be confusing if different parts of the language treat int as having different non-nullability. It would be really nice if int always means non-null, and int? always means mean nullable. The NNBD proposal achieves that.)

[yjbanov]

That's fine too, it was just an idea. I don't have enough context to know how best to proceed, so if you believe that NNBD and immutables should proceed completely independently, then they should :)

[jmesserly]

Makes sense :). Yeah, we seem to be gathering a lot of momentum behind Leaf's proposal. It's really exciting! I think we'll be able to apply the many lessons of Strong Mode to NNBD, to make the migration as easy & rewarding as possible. (e.g. ideally it's non-breaking for code that isn't migrated. Until you turn on NNBD, you don't break. Once you turn it on, you have to fix some errors, but you gain some degree of null safety, even if everything else isn't migrated yet. Once everything in an app is migrated, then it has sound null safety. It's pretty neat.)