New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Proposal for non-nullable types #28619

wants to merge 1 commit into
base: master


None yet
6 participants
Copy link

munificent commented Feb 3, 2017

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.


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:

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. (#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.

@googlebot googlebot added the cla: yes label Feb 3, 2017

@munificent munificent referenced this pull request Feb 3, 2017


Non-nullable type annotation syntax #27231

1 of 7 tasks complete

This comment has been minimized.

Copy link

whesse commented Sep 13, 2017

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.


This comment has been minimized.

Copy link

munificent commented Sep 14, 2017

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.


This comment has been minimized.

Copy link

hereisderek commented Aug 3, 2018

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


This comment has been minimized.

Copy link

munificent commented Aug 3, 2018

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. :)


This comment has been minimized.

Copy link

kirbyfan64 commented Aug 4, 2018

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


This comment has been minimized.

Copy link

munificent commented Aug 6, 2018

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

Yes! The beatings will continue until morale improves.


This comment has been minimized.

Copy link

mit-mit commented Nov 2, 2018

@munificent can we merge this proposal?


This comment has been minimized.

Copy link

munificent commented Nov 2, 2018

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?


This comment has been minimized.

Copy link

munificent commented Jan 11, 2019

This has been superceded by a new proposal.

@munificent munificent closed this Jan 11, 2019

@munificent munificent deleted the nnbd-proposal branch Jan 11, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment