I'm really sorry about my mispronunciation of "variable" and other English words. By the time I realized my error, it was too late to re-shoot. Apologies for butchering the English language. (Again.) I'll try to do better next time.
@@stainly7529 Bro the important thing is the improvement in the language, Swift has copied things from Java and C ++ 😜, but for that reason it is not necessary a Fanboy saying it everywhere, languages are to solve problems, and developers use them as tools, create problems = bad programmer 🙄😒
@@lx2222x Yup, its not about difficulty, its about innovation. No matter how hard something is its still some what achievable, but if lack of innovation you cant even imagine it.
@@stainly7529 I have seen this idea been discussed before swift existed. Swift made it mainstream. Chris Lattner never claimed that swift/him invented this. Swift is awesome and so is dart imo.
Yes, I think so too. It's one of those languages that was created with sense of reality. Just like javascript and php. Provides the needed and avoids unnecessary formalities.
I learnt about Flutter and Dart shortly after I started learning Kotlin. Not having null safety seemed like such a loss. Now that it'll be in Dart soon, I'm super happy to see that it'll be in Dart soon. And sound safety as well. Thanks Filip and the Flutter and Dart teams for all your hard work!
Since I coded with Dart, when I come across JavaScript & PHP variables, I ask myself what is this? what I supposed to do!? I love how dart make me unsafety on another language.
I love Dart! One of those languages that was created with sense of reality. Straight to the point without unnecessary formalities- just like javascript and php.
Null exceptions always happen and hurt a programmer's feelings :D nice feature. Loving the Dart and Flutter more and more everyday. Hopefully google never stops developing on this particular technology.
I like the new syntax but it would have been nice to introduce the concept in a more general form, i.e. tagged union, or better yet also introduce tuples to give dart the full power of algebraic data types.
C# has the same feature since C# 8, why there's no check here? 2:25 Complier analyzes code flow and warns if some value can be null where is shouldn't be
@@thedude61636 there is a difference in null-safety and sound null-safety. Kotlin is null-safe, which means you can declare fields to be non-nullable but technically things can still be null in some ways. We have it in a project that serializes Json. We can define properties as non-nullable, but it could still turn out to become null. With sound null-safety you are guaranteed it will never be null, allowing the compiler to be optimized. Swift for example is also sound null-safe.
@@SEGVeenstra So how exactly does Dart make sure that fields from a back-end API are null safe? Will it not allow non-null types from a network call, for instance?
I really like this null safety feature, but I do not really understand why it is not possible to throw a warning (like @ 3:38 ) when you declare a function that only allows non-null variables but you send a possible null variable, like @ 4:18. This kind of feels like an 'incomplete null safety' Or am I wrong?
nice disclaimer at the start, i figure it's meant to be easy to remove with youtube's video editor on pre-uploaded videos? for anyone watching in the future when null safety is stable, remove about 15 seconds from any timestamps that seem to link to the wrong part of the video and see if it makes any more sense, since that disclaimer is about 15 seconds long
I don't get it. I find null is a way to catch my mistakes which I think I would be more liable to miss and end up with subtle bugs, and the crashing thing, does it really happen? The ?. and ?? operators were already as much as I think we needed. Even with Delphi, 25 years ago, null exceptions were caught in the event loop and simply showed an error box, no crashing at all. And Flutter/Dart is arguably the new Delphi. C++, Java etc apps might bug out, but that was because they didn't have Anders Hejlsberg to show them the way. Can someone give me a persuasive example of how this improves our lives?
All the "old" null-value-errors occured at runtime. Which sucks. Now all null-value-errors occure at compile(!) time. If you program/script/tool compiles, it is guaranteed to not have any null-value-errors. That's why it's so awesome.
Thanks for this...there is a few of us taking a Beginner Flutter course with Angela Yu...and in one of the lesson she has us coding like this: void main() {
greet(greeting: 'Hey', namePerson: 'Cindy'); } void greet({String namePerson, String greeting}){ print("$greeting $namePerson"); } But this now throws a Null error in the latest Dart.......us beginners in the comments note that we can fix this either by putting a '?' at the end of the String...or by placing the word 'required' before 'String'...but what should we do in this case ideally? Thanks for any clues if you have a moment!
Yes, the type system is changing and thus code will clearly code will break, preexisting code may return "String" and return null sometimes, now that's not possible, instead you need "String?" - albeit an easy fix, but so is actually most code broken by this, even if a bit tedious to do everywhere (oh hey have you heard of that migration tool that makes it less tedious?)
Yeah I was waiting for that one too most of time in Flutter apps we have null due to initState, this feature also does the job but will have to add null checks everywhere
Indeed. The "late" keyword works very similarly to what non-sound null safety did, it simply means "This variable should always have a value by the time it is accessed, but i can't prove that by putting it in an initializer". An example would be a "Coffee" class that has "heat()", "cool()" and "serve()" methods, in the user of this coffee library they would always either heat or cool their coffee before serving it, otherwise that's invalid - heat() and cool() each assign the "temperature" field, and before they're called that field won't have a value. Dart's type system can't know you're meant to use that method before serve(), so when accessing the temperature to decide whether to serve "ice cold", "cool", "chilly", "room temperature", "warm", "hot" or "burning" coffee dart will tell you "Hey! that value can be null". To get around this you want a bang, but if that's the intended use, just put a bang everytime, you might wanna remove the explicit bang operator, so instead the "late" keyword at variable declaration would say "Hey i can't exactly prove this to you, but just trust me that when i access this i know it won't be null unless another developer did something wrong". When a variable has the "late" modifier, the same checks will be performed as when accessing null with a bang operator (or any variable access in non-nullsafe dart), mainly because the dart type system has trust issues from several null reference errors, and when the late variable does *not* have a value (i.e. null) it throws a LateInitializationError. There is one more benefit than just removing the bang, the "late" modifier doesn't actually change the type of the variable according to what values are allowed in it, so with a nullable type and then using a bang everywhere you can assign null, with a late modifier and non-nullable type you *cannot* assign null, once it *has* a value it will *always* have a value, even if it changes if the field/variable isn't final TL;DR it's like a nullable type you can't assign null, and the dart type system will null-check it for you and throw a LateInitializationError if it's uninitialized, and it signifies it will always be assigned before usage when the type system doesn't know that.
I am writing Kotlin day to day job, and it's also has sound null safety, when we have nullable variable we need to treat it properly otherwise compiler shows an error
Yes, there is a migration tool. I'm showing it off in this part of a different video: ua-cam.com/video/b6YntQSKS7g/v-deo.html. And yes, it is also optional. You have to actively opt into the feature.
The Dart team created a tool to help you migrate your code to use null safety: dart.dev/null-safety/migration-guide. There''s still some elbow grease required, but you're not on your own!
Knowing how annying NullPointerExceptions can be in Java and how NullSafety like this can be from Kotlin and Swift. I am going to love Dart even more than now... I hope it does grow out of java lol. Like. Go on. We have a Dart to javascript transcompiler. And I used it with a Cordova app a while back.
void main() { int? da=null; print('hello ${da+1 }'); } I don't understand the exact reason of null safety , above code need to apply null check. then whats the benefit ??
Its for handling code that is from other packages or deeply nested in the tree, when you are unsure whether the variable is null because the logic behind may not be obvious like the deliberate example above, I shall say the example is even foolish.
@@arslankhan8825 First of all, you need to move away from the traditional thinking of assigning a variable null just by making it a convenient "placeholder" to accept some values later. Before declaring the variable, you need to think does the variable make sense if been given a null value (hence giving a meaningful variable name is very important here), and must have a strong enough reason to do so. For example, you are creating a social media app, and have a user model with a string field called "displayName". Your app allows user to login as a guest, hence "displayName" make sense to be nullable as guest would not have any displayName, then it makes sense to declare it as sound null safe: String? displayName; When accessing the variable, it thus make sense also to check whether the variable is null before using it: print(displayName);
That's actually not correct, Rust does not have the concept of null, coming from RAII. It solves the underlying issue by using generic enums (Option and Result most of the times).
@@Nephtys1 Result is different. Rust does have the concept of null exactly in the way Dart has introduced it. Dart extracts null as a separated type in the type tree. Which, in effect, is the same as having a separate value for this which is None in Rust. Some in Rust or any non-Option type is the same as the default non-nullable introduced in Dart. Option in Rust has exactly the same meaning as "Type?" has now in Dart. Rust forces you to unwrap Option in the same way Dart forces you to handle null case.
By the way, the same behavior is in effect in modern Python using strict type annotations and a static check like mypy. Using Optional[Type] will result in the static check error unless you are handling None case successfully.
I really am looking for some "or alternative" code that looks up to the "alternative" value if the preceding value is null or undefined, like... Color color = favoriteColor | Colors.blue; where "|" is some "or alternative" operator, such that if favoriteColor is null, it opts to the Colors.blue value. I tried it on Dart but didn't work... or are there some syntax to that? I'm rooting for a response, and if there is no operator like that yet, I hope something comes up.
Hi. I have a question. If I fetch data as Json object from 'jsonplaceholder.typicode.com/albums' and show its contents after jsonDecode in listView builder with child: Text(drinks[index]['title']) where drinks is jsonDecode(response.body) then it gives error " An expression whose value can be 'null' must be null-checked before it can be dereferenced. Try checking that the value isn't 'null' before dereferencing it" and after putting the question mark after word 'drinks' removes the error. I tried searching about it but did find only declaration with question marks and null safety with '?.' , '??', '!' . Is child: Text(drinks?[index]['title']) correct and what does this question mark after drinks imply in layman language as it gets a little confusing.
Non-nullable fields are required to be initialized with values, though you can mark them "late" in the rare case that you aren't able to initialize them right away (but will before they're read).
Also, thanks to flow analysis, you can do something like this: int count; if (blah) { count = 10; } else { count = 0; } // ... Here, `count` is _non-nullable_, even though it starts uninitialized. Dart proves the count is not read before it is assigned, and allows this. Note that this only works for local variables (e.g. in functions). For class fields, Dart can't prove things like that, so you need something like `late`.
@@filiphracek Thanks. Since I do go-lang on server side I was secretly hoping it would be similar like in the Go where by default int is 0, string is "" etc. 😁 It will be interesting migration. 😁
Oh god, I developed an android app 2 years ago with older Dart version and I started to upgrade it in these days without knowing the language is almost completely changed.
I really don't understand the meaning of 'sound'. What does it mean? As a non native speaker, I only understand 'sound' as in 'sound wave' which we hear.
The word sound has a bunch of unrelated meanings. One of them is "dependable" or "reliable". In the context of null safety or type systems, it means the system is not approximating. It can _prove_ things are one way or another.
How to add null safety for this --> @Query ('SELECT * FROM Favorite WHERE uid=:uid AND id=:id') Future getFavInFavByUid(String uid,int id); Error --> Query method parameters have to be non-nullable. Define uid as non-nullable.
Okay I'm just starting to learn flutter and all that dart thingy but this feels like obsessive fear of nulls. You've explained that you're not allowing "developers" ( read as pseudo developers ) to use null pointers/values just because they can hurt themselves? That's like the worst case I can think of and forcing usage of such mechanisms is wrong on it's base. Imagine having huge system that relies on some object value, let's even imagine it will be amount deducted from your client bank account and just by forcing reassignments of that value you can recieve some random number at the end of processing because "it cannot be null". This way the application instead of throwing an exception will just say "ok, we deducted this random number from you client bank account". The real question is.. when we start treating developers as adults? Or when did we become so unaware that we need that much of assistance?
I really need to see rules of thumb on pre and post null-safety; best practice coding. It seems to me that I'm going to be using ? everywhere. A default of #000000 for a colour, for instance, is just wrong because it's completely arbitrary while seemingly correct it's actually incorrect where a colour should be intelligently selected, whereas there is nothing arbitrary about null. That goes for so much that I can't really see a place for non-null types; you just end up with the same messy, subtle bugs as some forms of Basic.
> A default of #000000 for a colour, for instance, is just wrong. Exactly. Null itself is not the problem. Nullable types are not _wrong_ per se. But after analysis of existing code, the Dart team learned that about 80-90% of variables are never (meant to be) null. So it makes sense to have non-nullable types by default. And when you need a nullable variable or field, you just add the ?. And it has the added benefit that the compiler now knows about this, and will force you to deal with possible null errors _before_ they happen at runtime.
I'm really sorry about my mispronunciation of "variable" and other English words. By the time I realized my error, it was too late to re-shoot. Apologies for butchering the English language. (Again.) I'll try to do better next time.
No worries
It actually gives it a little bit of a charm
Don't worry. I'm not native either. It's totally clear what you were meaning to say and the content is great!
Thanks all! I'm feeling a lot better about it. This community is so wonderful.
No need to apologize. Great video!
This is a beautiful thing. I can't imagine how hard it was to create this feature. Thank you flutter/dart devs :)
Yeah but it’s copied from other languages. Swift is the first to have it.
@@stainly7529 Bro the important thing is the improvement in the language, Swift has copied things from Java and C ++ 😜, but for that reason it is not necessary a Fanboy saying it everywhere, languages are to solve problems, and developers use them as tools, create problems = bad programmer 🙄😒
It isn't hard at all, it is actually easier
@@lx2222x Yup, its not about difficulty, its about innovation. No matter how hard something is its still some what achievable, but if lack of innovation you cant even imagine it.
@@stainly7529 I have seen this idea been discussed before swift existed. Swift made it mainstream. Chris Lattner never claimed that swift/him invented this. Swift is awesome and so is dart imo.
Dart is a really good language and I hope it grows out of Flutter's shadow.
Yes, I think so too. It's one of those languages that was created with sense of reality. Just like javascript and php. Provides the needed and avoids unnecessary formalities.
@@promisenwanno5969 except JavaScript is a mess and Dart isn't
Eminem Fan, you got my support
you are by far the best person explaining binary options! Thank you for putting these videos together. I look forward every week to see your videos!
This guy is really good at explaining Flutter stuff. Amazing video
I was expecting this to arrive sooner or later. Things are very easy when it has null safety such as in kotlin.
I learnt about Flutter and Dart shortly after I started learning Kotlin. Not having null safety seemed like such a loss. Now that it'll be in Dart soon, I'm super happy to see that it'll be in Dart soon. And sound safety as well. Thanks Filip and the Flutter and Dart teams for all your hard work!
Beautiful. This reminds of the time when I had to copy null-safety boilerplate code and paste through a number of dart files.
Thank you Dart devs ❤❤
I can't wait to be able to use this, I come from Kotlin and I totally miss this feature
Can anyone explain How this is different from the kotlin's null safety? What is this sound null safety and how is it different from the normal one?
I love you guys. Thank you for revive the joy of coding.
I sure will stay null safe, thanks for a down to earth presentation, you did a great job explaining.
Thank you Flutter for the great effort to solve this old problem, now I can program safely, thank you
Totally same with Swift, but it's still awesome. Thanks Flutter team :D
Since I coded with Dart, when I come across JavaScript & PHP variables, I ask myself what is this? what I supposed to do!?
I love how dart make me unsafety on another language.
Awesome!!!!!!! Thank you google!!! Flutter and dart are the best! Syntax is exactly like in swift I love it 😍
I love Dart! One of those languages that was created with sense of reality. Straight to the point without unnecessary formalities- just like javascript and php.
Null exceptions always happen and hurt a programmer's feelings :D nice feature. Loving the Dart and Flutter more and more everyday. Hopefully google never stops developing on this particular technology.
The devil works hard to introduce null errors but the dart development team works harder 😂🙏🏼
😂🤣
Awesome video! Great! Thanks for that! 🌟
my 2 hour search is over. At long last, a question mark saved the day!
I like the new syntax but it would have been nice to introduce the concept in a more general form, i.e. tagged union, or better yet also introduce tuples to give dart the full power of algebraic data types.
C# has the same feature since C# 8, why there's no check here? 2:25
Complier analyzes code flow and warns if some value can be null where is shouldn't be
Thank you for the hard work! Keep it up :)
This really changed a lot from the last time i coded in dart
now i'm feeling better. u made it so easy.. thank you :)
The introduction music is so soothing 😅
Love the feature, awesome vid!
Better than Kotlin, thank you so much
Kotlin has also null saftety
@@aadarsh8869 think he is aiming for the sound null safety. Which indeed makes it better then Kotlin imo
@@SEGVeenstra what is null sound exactly I'm not sure I understand it
@@thedude61636 there is a difference in null-safety and sound null-safety.
Kotlin is null-safe, which means you can declare fields to be non-nullable but technically things can still be null in some ways. We have it in a project that serializes Json. We can define properties as non-nullable, but it could still turn out to become null.
With sound null-safety you are guaranteed it will never be null, allowing the compiler to be optimized. Swift for example is also sound null-safe.
@@SEGVeenstra So how exactly does Dart make sure that fields from a back-end API are null safe? Will it not allow non-null types from a network call, for instance?
I wasn't able to understand what null safety mean but now i understand thank you
If im not mistaken, this was one of the neat features of ruby and using question mark , also available in typescript
I really like this null safety feature, but I do not really understand why it is not possible to throw a warning (like @ 3:38 ) when you declare a function that only allows non-null variables but you send a possible null variable, like @ 4:18. This kind of feels like an 'incomplete null safety' Or am I wrong?
Nice thank u.
i have a question. we should use ! when we guess maybe the value is null?
Yes. YES. *YES* THANK YOU😭😭😭😭♥️♥️♥️♥️
Awesome
Great feature from flutter team 👌
nice disclaimer at the start, i figure it's meant to be easy to remove with youtube's video editor on pre-uploaded videos? for anyone watching in the future when null safety is stable, remove about 15 seconds from any timestamps that seem to link to the wrong part of the video and see if it makes any more sense, since that disclaimer is about 15 seconds long
Really interesting
This is going to be great! Can't wait for it to be out of beta!
@Filip
is java has null safety?? I don't think @2:25
I don't get it. I find null is a way to catch my mistakes which I think I would be more liable to miss and end up with subtle bugs, and the crashing thing, does it really happen? The ?. and ?? operators were already as much as I think we needed. Even with Delphi, 25 years ago, null exceptions were caught in the event loop and simply showed an error box, no crashing at all. And Flutter/Dart is arguably the new Delphi. C++, Java etc apps might bug out, but that was because they didn't have Anders Hejlsberg to show them the way. Can someone give me a persuasive example of how this improves our lives?
All the "old" null-value-errors occured at runtime. Which sucks. Now all null-value-errors occure at compile(!) time. If you program/script/tool compiles, it is guaranteed to not have any null-value-errors. That's why it's so awesome.
@@Canaris ahh, I get it. That is awsome.
Very well explained!
Thanks for this...there is a few of us taking a Beginner Flutter course with Angela Yu...and in one of the lesson she has us coding like this:
void main() {
greet(greeting: 'Hey', namePerson: 'Cindy');
}
void greet({String namePerson, String greeting}){
print("$greeting $namePerson");
}
But this now throws a Null error in the latest Dart.......us beginners in the comments note that we can fix this either by putting a '?' at the end of the String...or by placing the word 'required' before 'String'...but what should we do in this case ideally? Thanks for any clues if you have a moment!
Will enabling null-safety, break existing code? Like moving from "@required" to "required" is already doing.
Yes, the type system is changing and thus code will clearly code will break, preexisting code may return "String" and return null sometimes, now that's not possible, instead you need "String?" - albeit an easy fix, but so is actually most code broken by this, even if a bit tedious to do everywhere (oh hey have you heard of that migration tool that makes it less tedious?)
Good feature = good practices = good code = good software = good results. Thx to devs
Thanks, very useful. And the best part that it looks almost identical to Swift.
How about the late keyword? Wasn't that part of dart's null safety feature?
Yeah I was waiting for that one too most of time in Flutter apps we have null due to initState, this feature also does the job but will have to add null checks everywhere
Yes, it is. new feature is ?, ! and late. you can read more here dart.dev/null-safety
Indeed. The "late" keyword works very similarly to what non-sound null safety did, it simply means "This variable should always have a value by the time it is accessed, but i can't prove that by putting it in an initializer".
An example would be a "Coffee" class that has "heat()", "cool()" and "serve()" methods, in the user of this coffee library they would always either heat or cool their coffee before serving it, otherwise that's invalid - heat() and cool() each assign the "temperature" field, and before they're called that field won't have a value.
Dart's type system can't know you're meant to use that method before serve(), so when accessing the temperature to decide whether to serve "ice cold", "cool", "chilly", "room temperature", "warm", "hot" or "burning" coffee dart will tell you "Hey! that value can be null".
To get around this you want a bang, but if that's the intended use, just put a bang everytime, you might wanna remove the explicit bang operator, so instead the "late" keyword at variable declaration would say "Hey i can't exactly prove this to you, but just trust me that when i access this i know it won't be null unless another developer did something wrong".
When a variable has the "late" modifier, the same checks will be performed as when accessing null with a bang operator (or any variable access in non-nullsafe dart), mainly because the dart type system has trust issues from several null reference errors, and when the late variable does *not* have a value (i.e. null) it throws a LateInitializationError.
There is one more benefit than just removing the bang, the "late" modifier doesn't actually change the type of the variable according to what values are allowed in it, so with a nullable type and then using a bang everywhere you can assign null, with a late modifier and non-nullable type you *cannot* assign null, once it *has* a value it will *always* have a value, even if it changes if the field/variable isn't final
TL;DR it's like a nullable type you can't assign null, and the dart type system will null-check it for you and throw a LateInitializationError if it's uninitialized, and it signifies it will always be assigned before usage when the type system doesn't know that.
This is great! Thank you!
Can anyone explain to me what's the difference between dart null safety and kotlin null safety??
I am writing Kotlin day to day job, and it's also has sound null safety, when we have nullable variable we need to treat it properly otherwise compiler shows an error
this is what we needed thanks
Thank you for such informative and easy to understand guide 😁
What about the existing codebase? Is null safety going to be optional? If not then will there be a official tool to help in migrating?
It's optional. Idk about a migration tool but I'd expect there will be
Yes, there is a migration tool. I'm showing it off in this part of a different video: ua-cam.com/video/b6YntQSKS7g/v-deo.html.
And yes, it is also optional. You have to actively opt into the feature.
This feature change everything, now all project make many errors? how deal with old project since they has many variable without question mark?
Elbow grease the heck out of that project, I say.
The Dart team created a tool to help you migrate your code to use null safety: dart.dev/null-safety/migration-guide. There''s still some elbow grease required, but you're not on your own!
Thanks for your explanation. What is your native language anyway?
"Stay null-safe out there", hahaha that's hilarious
Great explanation! Thanks a lot
Beautifuly explained. Thanks a lot 👍
I either check null value nd validate them or use null aware operator nd set the default value
Thanks a lot, great and simple video ❤
Thanks. Nice video as usual.
Knowing how annying NullPointerExceptions can be in Java and how NullSafety like this can be from Kotlin and Swift. I am going to love Dart even more than now... I hope it does grow out of java lol. Like. Go on. We have a Dart to javascript transcompiler. And I used it with a Cordova app a while back.
void main() {
int? da=null;
print('hello ${da+1 }');
}
I don't understand the exact reason of null safety , above code need to apply null check. then whats the benefit ??
Its for handling code that is from other packages or deeply nested in the tree, when you are unsure whether the variable is null because the logic behind may not be obvious like the deliberate example above, I shall say the example is even foolish.
@@yiweima4412 you mean in this case
int? da=null;
"da" variable should not be the nullable. am I right?
@@yiweima4412 could you explain it as an example
@@arslankhan8825 First of all, you need to move away from the traditional thinking of assigning a variable null just by making it a convenient "placeholder" to accept some values later.
Before declaring the variable, you need to think does the variable make sense if been given a null value (hence giving a meaningful variable name is very important here), and must have a strong enough reason to do so.
For example, you are creating a social media app, and have a user model with a string field called "displayName". Your app allows user to login as a guest, hence "displayName" make sense to be nullable as guest would not have any displayName, then it makes sense to declare it as sound null safe:
String? displayName;
When accessing the variable, it thus make sense also to check whether the variable is null before using it:
print(displayName);
@@yiweima4412 Thank you so much for a great detail, I will read it let you know if have any question. again Thank you so much
It worth to mention, that Rust does it in almost the same way. I was expecting to see Rust reference in the table presented in the video.
That's actually not correct, Rust does not have the concept of null, coming from RAII. It solves the underlying issue by using generic enums (Option and Result most of the times).
@@Nephtys1 Result is different.
Rust does have the concept of null exactly in the way Dart has introduced it.
Dart extracts null as a separated type in the type tree. Which, in effect, is the same as having a separate value for this which is None in Rust.
Some in Rust or any non-Option type is the same as the default non-nullable introduced in Dart.
Option in Rust has exactly the same meaning as "Type?" has now in Dart.
Rust forces you to unwrap Option in the same way Dart forces you to handle null case.
By the way, the same behavior is in effect in modern Python using strict type annotations and a static check like mypy.
Using Optional[Type] will result in the static check error unless you are handling None case successfully.
Instead of a null crash I now have empty screens which are harder to debug. Not sure if this is an advancement.
That's actually a great one.
Just one question, will I be able to cast Nullable values to non-Nullable and vice versa ?
Not flutter nor affiliated with flutter, but 3:49 will probably work with variable casting too
@@h8moss766 oh yes, I think you're right
Thank you, much appreciated!
Super video. Please create more news videos and tutorials.
Awesome!
🚀
is this already done in Mid Feb, 2021?
Hi, how do I add interstitial ads and admob banner ads to flutter ? Help me !
I really am looking for some "or alternative" code that looks up to the "alternative" value if the preceding value is null or undefined, like...
Color color = favoriteColor | Colors.blue;
where "|" is some "or alternative" operator, such that if favoriteColor is null, it opts to the Colors.blue value.
I tried it on Dart but didn't work... or are there some syntax to that?
I'm rooting for a response, and if there is no operator like that yet, I hope something comes up.
Color color = favoriteColor ?? Colors.blue
Hi. I have a question. If I fetch data as Json object from 'jsonplaceholder.typicode.com/albums' and show its contents after jsonDecode in listView builder with child: Text(drinks[index]['title'])
where drinks is jsonDecode(response.body) then it gives error " An expression whose value can be 'null' must be null-checked before it can be dereferenced.
Try checking that the value isn't 'null' before dereferencing it" and after putting the question mark after word 'drinks' removes the error. I tried searching about it but did find only declaration with question marks and null safety with '?.' , '??', '!' . Is child: Text(drinks?[index]['title']) correct and what does this question mark after drinks imply in layman language as it gets a little confusing.
why kotlin is not 'sound null safety' ?
Here's an analysis of Kotlin and other languages: github.com/dart-lang/language/blob/master/accepted/future-releases/nnbd/roadmap.md#kotlin
Any guard let/if let?
common, ? mark. Wasn't it possible to use something like annotations instead?
What about initial values?
int count;
Is count still null or 0? Will this be allowed without question mark?
Non-nullable fields are required to be initialized with values, though you can mark them "late" in the rare case that you aren't able to initialize them right away (but will before they're read).
Also, thanks to flow analysis, you can do something like this:
int count;
if (blah) {
count = 10;
} else {
count = 0;
}
// ...
Here, `count` is _non-nullable_, even though it starts uninitialized. Dart proves the count is not read before it is assigned, and allows this. Note that this only works for local variables (e.g. in functions). For class fields, Dart can't prove things like that, so you need something like `late`.
@@filiphracek Thanks. Since I do go-lang on server side I was secretly hoping it would be similar like in the Go where by default int is 0, string is "" etc. 😁 It will be interesting migration. 😁
You guys are missing the optional cats tag (as?). This is really important when you’re writing a safe null source code.
It is now possible. For example:
Color? color = aVariable as Color?
Great content!
Oh god, I developed an android app 2 years ago with older Dart version and I started to upgrade it in these days without knowing the language is almost completely changed.
sound great !! Wp
Finally, I can use it like Swift and Kotlin. When is it ready to production then?
I really don't understand the meaning of 'sound'. What does it mean? As a non native speaker, I only understand 'sound' as in 'sound wave' which we hear.
The word sound has a bunch of unrelated meanings. One of them is "dependable" or "reliable". In the context of null safety or type systems, it means the system is not approximating. It can _prove_ things are one way or another.
Can I get authorization to share to Chinese media? Such as WeChat.
Finally I can say goodbye for Red screen 🤩.
Also the larger general programming question is.... Is null a feature or bug?
I shall say both, its a bug if you dont use this feature correctly.
Similar to optionals in Swift. Nice
You missed an opportunity to make that last list thingsYouDontLikeAboutNullSafety? null
Great Video
Awesome language, and awesome community
Thanks
How to add null safety for this -->
@Query
('SELECT * FROM Favorite WHERE uid=:uid AND id=:id')
Future getFavInFavByUid(String uid,int id);
Error --> Query method parameters have to be non-nullable. Define uid as non-nullable.
Is it possible to write `null!` like in C# 8? :D
Last I checked, yes, it was possible! :) I guess it doesn't go against any of the static rules, though it _is_ silly.
Okay I'm just starting to learn flutter and all that dart thingy but this feels like obsessive fear of nulls. You've explained that you're not allowing "developers" ( read as pseudo developers ) to use null pointers/values just because they can hurt themselves? That's like the worst case I can think of and forcing usage of such mechanisms is wrong on it's base. Imagine having huge system that relies on some object value, let's even imagine it will be amount deducted from your client bank account and just by forcing reassignments of that value you can recieve some random number at the end of processing because "it cannot be null". This way the application instead of throwing an exception will just say "ok, we deducted this random number from you client bank account".
The real question is.. when we start treating developers as adults? Or when did we become so unaware that we need that much of assistance?
Please fix the subtitles 🙏
They're lagging
Great vid
Thank you!
take this feature in the compiler instead of tons of lines with questions marks
So this is just like optionals in swift.
Flutter forever
Indeed. Stay null-safe, everyone!
I really need to see rules of thumb on pre and post null-safety; best practice coding. It seems to me that I'm going to be using ? everywhere. A default of #000000 for a colour, for instance, is just wrong because it's completely arbitrary while seemingly correct it's actually incorrect where a colour should be intelligently selected, whereas there is nothing arbitrary about null. That goes for so much that I can't really see a place for non-null types; you just end up with the same messy, subtle bugs as some forms of Basic.
> A default of #000000 for a colour, for instance, is just wrong.
Exactly. Null itself is not the problem. Nullable types are not _wrong_ per se. But after analysis of existing code, the Dart team learned that about 80-90% of variables are never (meant to be) null. So it makes sense to have non-nullable types by default. And when you need a nullable variable or field, you just add the ?. And it has the added benefit that the compiler now knows about this, and will force you to deal with possible null errors _before_ they happen at runtime.