[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]
