Proposal for non-nullable types

[munificent]

This is the living proposal and tracking bug for adding non-nullable types (#22) to Dart. Two important caveats to keep in mind:

1. We have not committed to shipping this. We may discover that the overall
   usability impact is negative and Dart is better without them.

2. Because this involves breaking changes, it would not ship until Dart 2.0.

Prototype

In order to assess the usability, we're going to do a prototype first to see how it feels to convert a decent chunk of code (include our core libraries) to use non-nullable types.

The prototype lives on this branch: https://github.com/dart-lang/sdk/tree/prototype-nnbd

Implement static checking rules for non-nullable types

• Make types default to non-nullable.
• Report errors on state that is non-nullable and not initialized.
• Use ? to define a nullable type.
• Do the right type relations between nullable and non-nullable types.
• Report errors when downcasting from a nullable to a non-nullable type.
• Report errors on non-nullable optional parameters without default values.
• Test for errors when passing null or a non-nullable type to a non-nullable parameter.
• Decide on and implement the covariance behavior we want between nullable
  types. (Is int? subtype of num?? Is int it a subtype of num??)
• Incorporate nullable types into least upper bound calculation.
• Figure out how to handle nullable types in conditions (if (c), c ? ... : ..., c && ..., etc.)
• Define what methods are available on an object of nullable type.

Implement analysis rules to work with nullable types

• Allow nullable types as receivers for null-aware operators.
• Support == null and != null in type promotion.
• Handle is on nullable and non-nullable types in type promotion.
• Support ?? in type promotion. If the LHS side is a local variable, it should promote to non-nullable in the RHS.
• Remove the nullity of the LHS when determining the type of a ?? expression.
• Make sure as handles non-nullable types correctly. (In the analyzer.
  The runtime implementation is a different thing.)
• Handle a nullable type on the LHS of ??=.
• Warn on pointless check for null on non-nullable types (nonNullable == null or nonNullable != null).

Convert core libraries to be null-safe

• Generate report of static errors in core libraries.
• Figure out if we want Map[] to return a nullable value.
• Figure out how to handle new List(size).
• Fix the code.

Determine which extensions to the proposal we want to try

• Non-null assertion operator.
• Non-null top type above Object.
• Definite assignment analysis to allow uninitialized non-nullable
  local variables.

Convert some framework and library code to be null-safe

• AngularDart
• Flutter
• Mockito?

Convert an application or two to be null-safe

TODO: Which applications?

Once we get far enough through this, we should be able to confidently decide if
non-nullable types are right for Dart. Assuming they are, we move to:

Real implementation

This is a big feature with a lot of moving parts. I don't have a detailed plan
of everything that needs to be done, but I will progressively refine this as we
figure that out. The current plan is:

• Parse ? in type annotations. (Non-nullable type annotation syntax #27231)
• Add support for disabling non-null by default on a per-library/class basis (See G.2. Migration aids).

TODO: Fill in more here.

[whesse]

Can we put this document someplace other than on an unmerged branch? Unless we have some sort of system for tracking which branches have important information, but shouldn't be merged, then we don't know which branches besides master, dev, and stable are important.

[munificent]

Yeah, we can figure out some different process for tracking in-progress proposals. At the time that we decided on this, we were actually using GitHub. I guess we'll need to do something different now.

[hereisderek]

any update on this? would love better nullability handling like swift/kotlin

[munificent]

Sorry, no real update. We've been very focused on getting everything onto strong mode and getting Dart 2 shipped. That's a big migration with a lot of breakage, so it's consumed most of our time and most over our user's capacity to absorb breakage.

There is still a lot of hope we can get to non-nullable types before too long, but we'll need to rest a bit and give our customers a little breathing room after the migration we've dragged most of them through. For obvious reasons, adding non-nullable types will cause a lot of breakage and migration cost, so we want to be sensitive to user pain tolerance. :)

[refi64]

Just break everyone's code every other month, that way they get used to the breakage!

[munificent]

Just break everyone's code every other month, that way they get used to the breakage!

Yes! The beatings will continue until morale improves.

[mit-mit]

@munificent can we merge this proposal?

[munificent]

Oh, wow, I'd completely forgotten that I wrote this up.

If you'd like to use this as a starting for non-nullable types, sure. I don't think we want it in this repo, though. Want me to move it over to the language repo?

[munificent]

This has been superceded by a new proposal.