Amazing video! The only video that cleared up for me why there's such a thing as nullable ref types. In short, it was to eliminate ambiguity by forcing an explicit declaration of intent. I also enjoyed the latter half where you went into the operators and the generic example.
Thanks for the video! 👍 Sometime for new projects, I add Nullable to the csproj, so the code won't compile unless I fix nullability issues. This makes me understand the concept better.
I switched to using result / option / elevated types from the functional world in my c# and never looked back. Nullable and handling of them was a terrible idea for c#. I get its backward compatibility but time to evolve.
Came back for a refresher. A great summary, thanks! One thing I still ponder about is nullability on classes and records that are loading, e.g. config from disk etc., where you want to almost tell the compiler, “these fields are always set”. I guess this is adding ! to members but maybe there is a better way?
Thanks for the clear explanation on this. One thing that might be missing is that you can also get ris of the "may be null" warning by performing a null check somewhere before in the code. To me the addition of nullabel reference types possibly had the biggest impact of all newer features and i would never deactivate it on a new project now. Migrating old code can be a pain though ...
It's funny how c# is now doing the same thing java did with generics decades ago. Provide an optional "upgrade" to the new system and all old stuff is now a warning. And seeing that this "slow migration system" never completed in java we can assume that c# will have projects with nullabity and without for pretty much forever.
Thanks, very good stuff. What would you say are the benefits, for developers and the applications we build. I know you did mention it in the end, but I somehow got the impression of "just do it" rather than "do it so that your code will ..."
I think the benefit is more transparency to what you expected. By specifying nullability, you're telling the developer after you what you expect. Whereas before Nullable Reference Types, I didn't have a way of saying "This will never be null".
At 3:00 - "int? x = default" - the value is not 0 but null! (I was testing code as you were displaying it) Which brings me to my next question, why isn't it clear by the compiler what "default" value is!
@@swildermuth I am using .NET 7 and the dotnet-ef is 7.0.2 but in .NET 6 I also had the same warnings, I tried NullableReferenceTypes but not working in my case I can send more info if needed
Not sure how AI plays into it. But you're able to not use nullable reference types. There seems to be a separation into two dialects of the language over the years. C# 13 is the maturation of including more functional ideas, but it's all opt-in. You don't have to use it if it's not serving your needs.
Coming from an Fsharp perspective, nrt is helpful, but.. Like.. Not enough safety still. Lol. Types should never be null, null is terrible. Option is nicer, result is even better. Null was never a good idea.
I understand this perspective coming from F#, but C# is still an OOP language and the concept of NULL is still valid, especially when you're working with data stores that keep that concept.
Solid material. When you go over reference types nullability with such ease, you know straight away that you are listening to a an expert. Thanks.
That's very kind of you. Glad you liked it.
Shawn, you did an outstanding job of clarifying this new feature. I was struggling to understand why this was done. It now make sense to me. Thanks 😊
Happy to help!
Amazing video! The only video that cleared up for me why there's such a thing as nullable ref types. In short, it was to eliminate ambiguity by forcing an explicit declaration of intent. I also enjoyed the latter half where you went into the operators and the generic example.
Glad it helped!
great vid. You cleared up a lot of confusion I previously had!
Glad it helped. Took me a while to get my head around it too.
you have unusual way to simplify anything in a minute, great explanation as usual, thank you so much
Thanks for the video! 👍 Sometime for new projects, I add Nullable to the csproj, so the code won't compile unless I fix nullability issues. This makes me understand the concept better.
I switched to using result / option / elevated types from the functional world in my c# and never looked back. Nullable and handling of them was a terrible idea for c#. I get its backward compatibility but time to evolve.
Immutability and nullability are not the same issue. But I'm glad it is working for you.
Came back for a refresher. A great summary, thanks! One thing I still ponder about is nullability on classes and records that are loading, e.g. config from disk etc., where you want to almost tell the compiler, “these fields are always set”. I guess this is adding ! to members but maybe there is a better way?
You can say "required" and use non-nullable - they just need to be initialized in the constructor or object syntax.
I completely missed the required keyword - thanks!
This information was exactly what I was looking for. Greate stuff Shawn. Thanks for sharing your knowledge.
Glad it helped
most important change in the last 5 years. Paying attention to this as the tools are trying to make you do, massively improves your design.
How? Can you elaborate on this?
Extemely well done video, full and concise; have watched many video tutorials over the years both on YT, Pluralsight, etc; format is excellent.
Brilliantly explained in such a short way! Thanks a lot for your educational lessons 😊
Thanks for the clear explanation on this. One thing that might be missing is that you can also get ris of the "may be null" warning by performing a null check somewhere before in the code.
To me the addition of nullabel reference types possibly had the biggest impact of all newer features and i would never deactivate it on a new project now.
Migrating old code can be a pain though ...
Well, that was a clear explanation. Thanks Shawn.
Glad it was helpful!
Great video, really helped me thank you. Although the word null kept going funny in my head. Haha
Amazing video, thanks for putting it together!
Your content is amazing.. well done! don't stop!!
Ok!
Love this video, thanks Shawn
I appreciate it!
It's funny how c# is now doing the same thing java did with generics decades ago. Provide an optional "upgrade" to the new system and all old stuff is now a warning.
And seeing that this "slow migration system" never completed in java we can assume that c# will have projects with nullabity and without for pretty much forever.
Thanks, very good stuff. What would you say are the benefits, for developers and the applications we build. I know you did mention it in the end, but I somehow got the impression of "just do it" rather than "do it so that your code will ..."
I think the benefit is more transparency to what you expected. By specifying nullability, you're telling the developer after you what you expect. Whereas before Nullable Reference Types, I didn't have a way of saying "This will never be null".
@@swildermuth I also like that the code, when in runtime, will not (hopefully) get "null ref"-issues. Or am I misunderstanding ?
@@jedjohan That's true (harder to get null ref issues, but not impossible)
Nice explaination.
Glad you liked it
Thanks for great video!
My pleasure!
At 3:00 - "int? x = default" - the value is not 0 but null! (I was testing code as you were displaying it)
Which brings me to my next question, why isn't it clear by the compiler what "default" value is!
Null isn't the default for anything. Default for value types are typically 0 for numeric types.
Nice one. Thank you
Always welcome
good explanation
Thanks and welcome
when I scaffold the database using EF Core I get a lot of warnings about nullable
The scaffolding hasn't caught up with it. I don't have a good solution (adding the "#nullable disable" on every file isn't scalable really).
What version of .NET Core are you using? You might need to get the latest version of EF Tools. It is handling the null-ness in my recent projects.
@@swildermuth I am using .NET 7 and the dotnet-ef is 7.0.2 but in .NET 6 I also had the same warnings, I tried NullableReferenceTypes but not working in my case I can send more info if needed
9:25
In fact the code:
var len = user.Name?.Length;
len is of type int?
var len = user.Name!.Length;
len is of type int
How to create project by n new instead of dotnet new? when I use it I get error: n : The term 'n' is not recognized as the name of a cmdlet
Sorry, it is "dotnet new" - I just have a batch file that redirects to dotnet so I only have to type "n"
short and clear
Glad you liked it.
Cool channel. Thanks. I have been uneducated about how this feature works. Now I ain't. :D
This feature adds unnecessary complexity to the c# language.
C# is a Frankenstein language for a long time. Now this nullable stupity is made so that the code is easily read and used by the AI... I hate it
Not sure how AI plays into it. But you're able to not use nullable reference types. There seems to be a separation into two dialects of the language over the years. C# 13 is the maturation of including more functional ideas, but it's all opt-in. You don't have to use it if it's not serving your needs.
Coming from an Fsharp perspective, nrt is helpful, but.. Like.. Not enough safety still. Lol. Types should never be null, null is terrible. Option is nicer, result is even better. Null was never a good idea.
I understand this perspective coming from F#, but C# is still an OOP language and the concept of NULL is still valid, especially when you're working with data stores that keep that concept.
Great explanation
Glad you liked it.