[breaking change] Discontinue non-null-safe mode #49530
Dart 3 & discontinuation of support for non-sound null safety
In the Dart 2.12 release, Dart introduced sound null safety. When this was introduced we used an opt-in model: Only code that was opting into language version 2.12 or later was run with null safety. Dart developers could migrate their code in a stepwise fashion.
We are now planning a Dart 3 release -- tentatively slated for release by mid-2023 -- where we plan on only supporting Dart code that uses full sound null safety. This means that the null safety legacy mode will be discontinued, and that all code must run with full sound null safety.`
The reasons for making this change are:
Everything uses sound null safety in Dart 3
In Dart 3, only sound null safety is supported.
Backwards compatibility for null safe packages
Dart 3 sound null safety will be backwards compatible with with code already migrated to use null safety in language versions 2.12 and later.
This means that a Dart 3.0 SDK will allow SDK constraints where the lower-bound is at least
This allows developers to use Dart 3 sound null safety with packages that have been migrated to 2.12 null safety.
Note that Dart 3 may contain other breaking changes. For example some core library APIs are discontinued in Dart 3, which may mean that some packages may not be compatible with Dart 3 even if they have migrated to null safety with 2.12. We'll release a Dart 3 alpha release (see below) that can be used to test if code is affected by any of these breaking changes.
Roll out plan
We expect to roll out a Dart 3 alpha release several months prior to Dart 3 stable. This release will allow for testing if a package or app is compatible with Dart 3. The alpha release is not likely to contain other Dart 3 feature work unrelated to sound null safety, but will contain all planned breaking changes.
Later we also plan on releasing a Dart 3 beta release that is more feature complete.
Finally, we'll release the Dart 3.0 stable release, tentatively by mid-2023.
Work item tracking
Dart 2.19 stable, and associated Flutter stable
Dart 3 alpha
Dart 3 beta
The text was updated successfully, but these errors were encountered:
Can anyone advise? I have two projects, each containing 300+ classes. Just turning on SDK 2.19 more than 3000 compile issues. The work required to fix 3000+ issues per project, and more arising, is waaaaay more than a person can handle in any reasonable time amount.
Do you have any suggestions? Maybe make a migration tool that sets all questionable variables to nullables? And each access to ! ?
Would this make sense?
I read somewhere there is already a migration tool, but it is buggy, or something like that.
Please see the steps here in this guide. You are not expected to do this manually.
This includes instructions on how to use the null safety migration tool. This tool has successfully migrated millions of lines of code by now, so while I can't rule out potentially hitting an issue, it should have a pretty good chance of working.
@mit-mit Thank you so much for your info. I used the migrations tool, and it changed 90% of the files - an amazing number, imho.
I started fixing the compile issues - hundreds of them.
Then tried to start the app - it crashed a lot because of nulls.
I am now left with 700 warnings and forced to test ALL paths of the app code - a truly gargantuan task.
I found some bugs(?):
now I have to specify
To put it short:
I cannot even imagine what happens when a really big application is forced to migrate...
Please consider these points when deciding to discontinue support. Maybe move this to 2055? :)
Thank you again for your support!
I personally did not use dart migrate on my project because it was small enough to do it by hand. My suggestions:
@adrianvintu if your app passes full analysis (
I think you may have the wrong mental model about the migration based on a comment like "this is no longer possible var widgets = ..length = 1; type 'Null' is not a subtype of type 'Widget' in type cast I understand this is not related to migration".
With null safety, variables are non-nullable by default. So