Repository navigation
Non-nullable type annotation syntax #27231
Description
This is the tracking bug for the real implementation of the postfix ? syntax to mark a type annotation as nullable as part of supporting non-nullable types (#28619). See the "Syntax" section of the proposal for details.
Since we're still only in the prototype phase, consider this bug to be on hold. If we decide to go ahead and ship a real implementation, I'll update this.
Flag
While this is being implemented, to ensure we don't expose users to inconsistency in our tools, it should be put behind a flag named nnbd.
Tracking issues
- Analyzer (Analyzer: Non-nullable type annotation syntax #27232)
- dart2js (Analyzer: Non-nullable type annotation syntax #27232)
- dev_compiler(dev_compiler: Non-nullable type annotation syntax #27234)
- Formatter (Support NNBD syntax dart_style#536)
- Specification (Specification: Non-nullable type annotation syntax #27235)
- VM (VM: Non-nullable type annotation syntax #27236)
- IntelliJ-plugin (IntelliJ-plugin: Non-nullable type annotation syntax #27237)
Reacted by Kevin Moore, Benjamin Strauß, Günter Zöchbauer, Yegor, elijahdorman, John Ryan, Pat Kujawa, Ben Campbell, Tod Bachman, Anton Astashov and 46 more
Reacted by Denis Lepyohin
Reacted by Alec Henninger, Günter Zöchbauer, Anton Astashov, George Lesica, anonymous anonymous, Tanguy Krotoff, Gregor, Honza Bittner, Michael Walcott, Łukasz Wasylkowski and 4 more
Reacted by Joshua Harms, Łukasz Wasylkowski, Yegor, Abdu Bsruki, Graham Baldeck, Tim Rijckaert and Erli Soares
Activity
crelier commentedon Sep 2, 2016
Just curious, why was '?' chosen? It seems very counter-intuitive to me, since a question mark implies some kind of optionality. In this case, we rather want to express a restriction. A more assertive exclamation mark would be more appropriate, in my opinion, but I did not study possible grammar conflicts, if that is the reason of this choice.
lrhn commentedon Sep 3, 2016
The question mark means that the type is nullable/optionally null/union of type and Null, and its absence means that the type is just itself.
donny-dont commentedon Sep 3, 2016
Any chance union types will come along with this? They seem to be natural fits.
dynaxis commentedon Sep 4, 2016
This seems just an experiment for now. But I'd like to note that there might be needs for addition of APIs to the standard library. For instance, Kotlin has
filterNotNullandmapNotNullon nullable sequence or collection, which return one with non-nullable element type. Dart'sStreamand collections would be better to have such new APIs. They can definitely be implemented in user codes, but are really clumsy to do so.crelier commentedon Sep 4, 2016
@lrhn Oh, I see. The title is misleading and the text does not clarify. It should actually be "Nullable type annotation syntax" instead of "Non-nullable type annotation syntax".
zoechi commentedon Sep 5, 2016
@tantumizer
This is shorter
See also #24892
I find
x!!a bit cryptic.If the return type for the function that contains this code is a non-nullable type it should throw in checked mode anyway and make the check and
throwredundant.lrhn commentedon Sep 5, 2016
@tatumizer
Good questions, some not decided yet.
Optional parameters: If nothing else changes, you'll have to make them nullable by adding a
?to the type. After all, that is their type. We may consider allowing you to make them non-nullable if they have a non-null default value. If we do that, we should probably also change how default parameters work by making an explicitnullargument be equivalent to not having the argument at all. There is some design-space here to explore.For a nullable
var, it's not really a problem as we are moving towards Strong Mode wherevarmeans to infer the type. You can writedynamic?but sincenullis already assignable todynamic, I thinkdynamic?will just mean the same asdynamic(so we may disallow it entirely, there is no reason to have two ways to write the same thing). Same forObjectandNull.Too many question-marks. Likely true, but they are consistently about
null(except for the original?:conditional operator).A
not nullassertion (that is: take nullable value, throw if it's null, otherwise we know the type).That could just be
x as Fooif the type ofxisFoo?. We will have to changeasto not allownullfor non-nullable types, you would then writex as Foo?to get the current behavior.We are also considering shorthands to quickly coerce a value to an expected type. Maybe
x!will check for null ifxhas typeFoo?and it's used in a position where a (non-nullable)Foois needed. Maybe that's just being too clever by half.zoechi commentedon Sep 5, 2016
If you have
then
?? throw new NullPointerException();is redundant becauseStringalready is non-nullable and checked mode should throw.53 remaining items
donny-dont commentedon Jan 14, 2017
@munificent the link to the dart2js bug is wrong up top. Off by one error 😉
osdiab commentedon Jun 27, 2018
Is this not happening? :/ I find this to be a really useful concept for ensuring type safety of my code, and along with the lack of union types is making me wary of switching from TypeScript/React Native to Dart/Flutter in future projects.
munificent commentedon Jun 27, 2018
It's not happening yet. Moving Dart to strong mode is a necessary pre-condition for non-nullable types. We are doing that in Dart 2. We hoped to get non-nullable types in at the same time, but it proved to be too big of a change to fit into 2.0, so it's going to have to wait until a later version.
segfaultmedaddy commentedon Sep 9, 2018
So now as Dart 2.0 is released would be there any changes so it finally get happened?
munificent commentedon Sep 10, 2018
Now all that's left is to design and implement non-nullable types, figure out a migration plan, add language features to make them more usable, etc. :) Basically, we have to do all the work. It's a giant feature.
gbaldeck commentedon Jan 23, 2019
If this year there was only one feature that dart shipped, this would be my choice. I really hope it becomes a high priority soon.
mraleph commentedon Jan 24, 2019
@gbaldeck and that's exactly what is happening this year see dart-lang/language#110 :)
@munificent Should we close this and all associated issues and indicate that people can follow along the new language process in the language repo?
munificent commentedon Jan 24, 2019
Yeah, good call. Closing this in favor of dart-lang/language#110 which is the main tracking issue for the current plan to add non-nullable types.