[MUSIC PLAYING]
SPEAKER 1: As of November 2020, null safety is in beta.
This following video shows codes that
will only work if you've opted into the feature.
Learn more at dart.dev/null-safety.
SPEAKER 2: Generally, variables hold some kind of a value.
An integer can be 42, or 0, or minus 1.
A string can be "hello world!"
or "what?"
But most programming languages, including Dart,
also have the notion of a null value, no value.
For example, it makes sense for a favorite color variable
to be null.
Some people just don't have a favorite color.
This creates a problem, though.
If variables can be of a certain type, like integer or color,
or null, then you must think, every time
you use it, is this color a color or is it null?
Is this value in this list of integers an integer,
or is it null?
Experience shows that it's hard to think about this all
the time, and that developers tend to introduce
null errors quite often.
And numbers are bad, because they
can crash your app, which is something
that users don't appreciate.
Enter null safety.
By default, Dart now assumes that your variables are never
null.
For example, the age variable here is not non-nullable.
It must never be assigned null.
That's almost like a double negative,
so let me put it another way.
The age variable must always be some number.
It can't be null.
This is the default. Types are non-nullable by default.
You can still use null for variables,
but you have to be explicit about it.
Here we are saying that favoriteColor
is nullable by adding the question mark.
The variable can be null.
It can be a color or null.
Because we're explicit, Dart can now
help us avoid the errors I mentioned.
If you try to use favorite color as if it was color,
forgetting about the possibility of null, Dart will tell you.
This makes your code safer.
What's more, Dart's null safety is sound.
When Dart determines that a variable is non-nullable,
that variable is always non-nullable.
Many other programming languages have unsound null safety,
and in many cases still need to perform runtime checks.
Dart shares sound null safety with Swift, but not very many
other programming languages.
Because of sound null safety, Dart
can optimize your code to run faster.
So it's not just safer, it's also faster.
What does all this mean for you, the developer?
As I said in the beginning, most variables
always have some kind of value and never have no value.
In other words, they are non-nullable,
which is a fancy way of saying they can't have null in them.
Therefore, most of your code should look like this--
no question marks, no null checks, nothing.
When you expect a variable to be potentially null,
then you must explicitly mark it as nullable.
You do that with the question mark.
This doesn't just apply to verbal declarations,
but also to function arguments, function returns,
generic types, and so on
Dart will then help you avoid null-related errors.
Basically it will ask you to add null checks where appropriate,
and deal with a null that you might have forgotten about.
What about the in-between situations though?
If you're assigning a non-nullable variable
to a nullable field, that's OK.
A color that's always a color and never null
can be accepted by a function that
expects either a color or null.
The other way around is trickier.
A nullable color, which can be a color or null,
cannot be given to a function that expects a non-nullable
color.
Said differently, if your function says,
I never take nulls, my argument is non-nullable,
you can't give it something that might be null.
So how do you deal with that situation?
You have a few possibilities.
One, avoid the call altogether if you know it's null.
Two, use some other value instead
when you know it's null.
Three, force a nullable with an exclamation mark.
That's similar to writing a null check
and throwing an exception if it fails.
So you should only do this if you're
100% sure the variable is not null in this particular case,
even though the type is nullable.
For example, you may know something about
your program's domain that Dart cannot possibly know.
Suffice to say, you should avoid the exclamation mark
as much as possible.
There you have it.
Null safety makes your code safer
and even makes it run faster with minimal impact
on how you write it.
Dart is smart enough in its analysis
to let you do things without too much null-related boilerplate,
but doesn't let you introduce null reference backs.
That's it for this video.
It was a mere introduction.
Check out dart.dev/null-safety for more.
And stay null-safe out there.
[MUSIC PLAYING]