Should you stop returning "null"? | Functional C# 

Well, quality of code sure has a cost...

With the vast amount of the BCL that was null annotated in net5 and if you treat warnings as errors (which you should) then yeah. NRT is now the a fitting, and more idiomatic c# solution.

even tho u have to check if has value in some cases

@@Luturol You could mark it as non Nullable reference type and throw null exception in the method, outside the method you will be 100% sure it can't be null, ergo, there is no need to check fo nulls, there is no boilerplate code.

Exactly! Not much easier, it's way cleaner to the code.

It’s one of the reasons why I love Kotlin so much. With C# it’s obviously an afterthought and it’s up to the user to adopt which is understandable but sad if it doesn’t get adopted widely

If the only way to access the object is by "Match" then effectively you've compiler enforced the check, since you can't call Match for the Some only case, you MUST provide a None case or it will fail compilation. It moves the error from runtime to compile time. you can also do this post C# 8 by enabling Nullable reference types and treating all warnings as errors.

The point is not to remove the necessity of checking null values but to force the caller of a function to acknowledge the fact that it can return an empty value. This is mostly a safety/readability feature.

@@r.c8756 I read what you're saying but all I hear in my head is 'People are lazy in reading and writing documentation and have very dangerous assumptions.' 🤣 But seriously, developers that want to use this have had ways of doing this since day 1 of C# (me in part). Developers that don't want to use this won't (me in another part, bit of internally (protected) split on this issue). 😉

@@rolandtennapel5058 it's not about being lazy, missing a null check is a common bug even for seasoned developers. Having tools to help you keep your code sound is never a bad thing, and the possibility of trading a runtime error for a compile time error is always a plus. Java has Optional types as well and they are very useful.

@@rolandtennapel5058 Documentation will never replace code quality and yes, people are lazy. They sometimes make mistakes and sometimes, they even plainly suck. This is kind of a negative way of looking at things but on the other hand, making things safe is thinking of the worse that can happen and then think of a way to prevent it to happen. As a programmer, you should always assume that the next guys who’s gonna use your code will mess up in the worse possible way. (and if you have a bit of experience in the field, you know that this happen more often than you’d hope...). So an important part of our job is to write code in a way that they can’t.

I prefer the try-pattern with bool TryGetSomething(out SomeType result). I n this solution the decision making is also implied and I don't need any unnecessary lambdas.

Yeah C# was basically trying to get to Kotlin's implementation with C# 8 but the problem is that null worked like this for so many years that it's been engraved to anyone's muscle memory and it's so hard to change your mind on something that you've been doing for years.

I agree, the code is much less readable in this case. I’m all for optional values (like std::optional) but I wouldn’t use it for nullables because a nullable already has the functionality built in, ergo the ability to check for a null reference.

I really don’t understand this disposition of mind. Questioning practices is the most elementary step of learning and improving and you never stop doing that in a career. With that mindset you can never improve... In only looks less readable because it challenges your habits.

@@r.c8756 It's good to question things and consider new approaches, but you're stepping backwards if you add unneeded complexity. Less readable is less readable; that has nothing to do with habits being challenged. A software engineer, especially a contractor, can't be successful for any considerable number of years without challenging their habits, getting outside their comfort zones, and expanding their knowledge on a consistent basis. Not returning null and engineering a work around to avoid it is none of those.

The thing I like about the approach, personally, is that the design tells you that you have to account for "none." Nullable reference types are good for that too.

@@logank.70 Exactly re nullable ref types, so why go to the trouble of the design? Just seems to be a case of overthinking and recreating the wheel simply because the programmer doesn't want to use nullable refs already included in the framework. Besides, nullables are something every programmer should already know how to handle, even a junior one.

@Ishaan Jaxtyn Insane! It took me 5 minutes to say it worked!

You'd be incorrect. That's not what null is. The type system does not give us a way of representing "nothing" or "no value". So we use null to do that, even though it's problematic. And since everybody has treated it that way for so long, the compiler team had to create work-arounds so people would stop hurting themselves with it.

There are no safe operations on null, though. That is the difference. The world does need some Empty or Bottom type. That should not be a type whose default behaviour is to go kaboom, though. It's a type whose default behaviour should be a no-op, with a reminder to deal with the no-op, *without* encouraging people to just swallow catches, or return null to the next poor sap who needs to do the exact same things you just did... possibly without the same level of concern for soundness of the logical flow of the application.

In that case - better way to prevent new programmers from doing errors is not allow them to code. :D

@@amuuuinjured LoL

Spend twice as much time testing than you do coding and it won't matter. Either you coded for null or you didn't and if you didn't it's a bug that you must fix.

@@MoMadNU Why waste time testing things the compiler can trivially verify for you? Test time is better than runtime, but compile time is better still. (Not to mention the more explicit/correct API)

@@berylliosis5250 The compiler cannot detect a null reference exception which represents 90% of the exceptions you will encounter because of bugs in your code.

That was one of the first things I noticed when I played around with F#. Option is built-in.

And its simpler to check if null... In thus case we need to use additional library and still write some checking code

@@willembeltman Checking inside the function means you don't have to remember to check outside the function. 😉

Option is basically just a list of 0 or 1. Some implementations of option actually just extend IEnumerable and essentially just provide convenience methods for returning a list of 1 or 0

It works but it’s a (dirty) hack which damages the readability of your code. The very point of typing is to add meaning to otherwise completely abstract and decontextualized algorithms.

@@r.c8756 Disagree with the first sentence and agree with second sentence. :)

@@aborisov20 Returning an IEnumerable tells whoever read your code that they should expect several elements. This is deceitful and therefore, bad practice. Correct use of types, variable and method name should describe as accurately as possible their behavior... What do you disagree with exactly ?

@@r.c8756 Nothing related to term "dirty hack". Just expected behaviour. By design.

Based on my personal experience in the past 2 years, it’s very much the opposite actually. It has completely removed any NREs, the code it way more predictable and deterministic and the performance degradation is so slim it’s not even a factor. Not only that but since these types are structs there is minimal memory footprint changes.

It was a big mistake to make the nullability (and omnipresent `default`) concept core to the language. Could you provide an example of weird behavior with Option? Besides nulls being converted to None.

You can avoid null check, but cannot avoid match

I use switch expressions all the time now. C# 9 makes writing functional code in C# much easier.

One is optional one is mandatory. That's the difference.

Very good question. It's my bad that I didn't cover it during the video. On this specific example: The Non-Option approach will execute at a mean time of 146 nanoseconds and will allocate 168 bytes of memory (it's probably the Guid object allocation). The Option approach will execute at a mean time of 222 nanoseconds and will allocate 296 bytes of memory (it's the Guid plus the Option object, even though this is stack memory allocation due to Option being a struct)

With the latest C#, if enabled, there is nullable reference types similar to int?. With this all reference types by default are not nullable which can mitigate much of this out and the time implications will be reduced. When you use nullable reference types you have the same .HasValue and .Value properties along with operators like ?? and .? Personally I have come around to null is evil. I have lost count of the null exception errors I have chased down over the decades I have done at the code face. It is far better to use this sort of technique to force devs to have to deal with the full types of the return value instead of mask it. If you get an Option or MyClass? returned you know you have the chance you have no value and are forced to handle it. If you just get MyClass returned without that protection you have no idea. It makes the function more explicit. Take the following public Result DoTheThing(); You can instantly see you might get a "good response" that might have a value or you get an error. No need to dig into the code to see if it can throw etc

The thing with Nullable reference types is that it doesn't really prevent you from handling them. You can still use the bang operator (!) to suppress it and it's not an error until you explicitly mark it as one. It's basically an afterthought and realistically, people won't instantly jump into using it because they can get away without using it. Option is something that you need to acknowledge no matter what, which i prefer.

@@nickchapsas this is a very interesting discussion and maybe worth picking up in another video showing the approaches side by side with a more complex example. I'm currently leaning towards nullable reference types because I have seen code with pretty big classes and handling the matches made it quite difficult to read and understand. And with a good culture where you try to eliminate all the warnings I think its nice for a lot of cases. Also I just remembered that you can install the FxCop nuget package and have the null reference warnings pop up as errors instead so the project does not compile.. I probably should try that

You can configure the code to not compile if there are such warnings, and if one use ! forging operator, well, what he's saying is that "ok, I know it can be null but I don't care" which doesn't mean he forgot about null-check, pretty much the opposite. I think using yet another library to handle a case that's already done by the language is just too much. It was useful before c#8 but now it's just more complexity

These containers aren't for low-level operations, and aren't for async values (that last part isn't exactly true... *this* container isn't for async values... async/await itself hides the concept of containerizing requests), they're for code composition. At any point in your example, some programmer could have your instance mutated by 8 different threads at the same time, with no thread locks; how is null going to help you in that case? If that's how your team writes code, then nothing can save you. The class is already there and uninitialized, or poorly reconfigured. If my code needs to return an A, but in order to make an A, I need an x which I have, and a y which I don't, I can solve that in ways better than passing around uninitialized instances. async GetA () { x = GetLocalX(); potentialY = await GetY(); potentialA = potentialY.Map(y => new A(x, y), None); return potentialA; } I am only going to make an A in the case that I know I can correctly construct that instance. And what the next user gets is something that they can operate on (through Mapping from A -> B), Filtering from (A -> None) in the case they aren't interested in that instance, handling the case where they got nothing, or just passing it on to the next person down the line, who will do any or all of the above, before themselves passing it on. It benefits the system in general, to write it in such a way that you have no incomplete or ill-configured objects/structs/sets/etc floating around, regardless of what architecture you're using for code composition.

"None" does not have the form of the class you are trying to access. Lets say you have a method that returns an object of type Option. If you call that method, and it happens to return Some, you can think of that as wrapping a Person object. If you want to use that object, you kinda have to reach in and get it. In other words, you can't just treat the Option object like it's a Person object. On the other hand, if you call that method and it happens to return None, there is no Person object to access. In reality, that Option is probably wrapping a null Person object. But that's just an implementation detail, you have no way of accessing it. You can't accidentally access it. People in these comments seem to think the point is to have a clever way around null checking. That's not it. The point is to have a real representation of "no value" without bringing null into the equation at all.

Maybe this example doesn’t illustrate the point as well as I’d like it to because it’s a very simple example. Realistically you would have different return types on each layer and you wouldn’t just be able to return option itself. The whole point of option is that you cannot get the value without handling the None scenario and that needs to happen across your application. Also, like I said in a different comment, performance impact is negligible.

@@nickchapsas thanks, it would be great if you have another video which covers the said point.

@@nickchapsas "performance impact is negligible." Famous last words before performance issues commmence ;)

@@airjuri I can guarantee with 100% confidence that this will be the last thing that you will need to optimize in your application

I do actually and I see them as a different thing. Nullable types and the compiler can lie and Jon Skeet has a great talk about that. It’s also to the library author’s discretion to use them. Option beats all that with a clean forced matching scenario

👆👆 yep. what’s worse about this is these cultural forces (not the beautiful language itself) ends up ruining the language in practice (because to use it you have to work in environments with such enforced paradigms), so then we all have to go back to C to escape this!

It will only force you if you enable nullable reference types as errors in your project and even then you can ignore if you if think you know better than the compiler with the ! operator

@@nickchapsas Yes, that ! is true. I do that 😝 But usually, only in cases I know would have had an error a long time ago if what I am accessing is null. Maybe it proves your point. I have never seen the language extension library you talk about. I might check it out, although like I had said I use a lot of F#, so I might have a method returning FSharpOption or FSharpResult. This library probably wouldn't work on those.

Because your code is safer. The benchmarks show a performance degradation in the class of a few nanoseconds for the benefit of NRE elimination and for predictable code. Ofc it’s something you can ship if you commit to using null reference types properly but again that’s up to the dev

@@nickchapsas if you put a check for null. Where the dangerous path of that ? Plus this nanosecond with a Friday, science software, bi software, financial software... And of course, change all your code... It's the basic of a language null treatment.... It's like... We are using a stable old fashion jeans... Let's create a radical new one.

@@ericfelipe2011 The dangerous part is that it's up to the developer to put the null check in. What you're assuming is that every nullable thing will be null checked at the right place, which is simply not true.

@@nickchapsas with new coalesce it's even simpler Return object?.property ?? New list() With so many code analítics, it's can be configured yo show a warning of a null reference or something.

@@ericfelipe2011 Coalesce is a completely different feature and has nothing to do with this. I agree that Null reference types can be configured to give a similar experience but it's still up to the developers and the team to enable it and make it mandatory (error instead of warning)

Exceptions should be exceptional. I am not a fan of taking a performance hit just to have an easy way out of the application's flow. It's convinient, sure, but it's by no means good.

It would work in the exact same way. You'd just have to return Task.

The potential problem is not fixed at all. It's just another, less readable syntax to prevent it.

Easy problem? Null is definitly not an easy problem, there is a reason why the creator regrets it and some new languages like Rust don't have it at all.

Hey Uzair, I really appreciate the comment. This is exactly why I make these videos. It doesn't need to be something that you will use but it's good to know that there is also this thing here that might be of use.

@@nickchapsas indeed exploring different options are definitely worth the time you never know when you might need that different approach. Keep it up 👍

I am looking for this too. I personally prefer using c# nullable between repository and services layers. But I think that option may serve better between services and controllers layers. It is great, Thanks for sharing.

I mean I like it and have been pushing to this kind of structures for years, with no results ever

Null coalescing has nothing to do with Option's null handling. Sure it's a fallback but it's not different than an if == null check that can be omitted if the writer isn't careful. It doesn't force you to handle it. Option forces you to acknowledge the fact that this value can be null and demands you to handle it somehow. There is no way around it. It's basically the null reference type feature of C# 8 before C# 8 became a thing. I don't think that NREs can be a metric to determin whether an application is poorly coded or not. If the value can be null then you should be forced to acknowledge it. Whether that is via the Null Refernece Types of C#8 or Option, it doens't matter.

@@nickchapsas i apologize, your right, my statement regarding NRE’s was a generalization... but isn’t the use of option just a way of saying if object A is null, return object B... Isn’t null coalescing doing the same thing? I do like the idea of I’m returning a customer object of null that maybe had a boolean flag of CustomersFound set to false rather than null. That to me makes sense...

@@ajcroteau0928 So you're right, the outcome is the same and in fact there will also be a small performance hit due to how the Option struct works. The difference is that Option doesn't give you the option (no pun intended) to not ackowledge the potential of a null. Basically you could write the same code without Option but using it guarantees, no matter what, that the developer has absolutely no way to mess it up by not handling the null option. It forces you to write more robust code.

null awareness is optional and can be skipped. Option is a discriminated union and it has to be handled no matter what. It's safer

@@nickchapsas you're referring to the second delegate? Uhh true i guess. Although you can pass null to that one as well but then you did it intentionally while null awareness can be forgotten. Yeah good point, got it.

Well, that’s the downside of using that kind of functionality. This kind of decision should probably be best taken and enforced as a team and not just as a personal initiative

Which is probably what he uses regularly, but for such a video other people might not get what is happening, doing it manually is better for explaining.

As I explained on another comment, the performance overhead is negligible so I don't really agree with that part of the argument. In fact, it only has to save you from a single NRE to make it worth it and it definitely will, there is no question about it. I can guarantee you that there will be at least 50 different things that you can optimize on a system before you ever get to optimizing for the 35 nanoseconds that each Option will add to your system. I can however get behind not being the cup of tea of everybody especially if you haven't worked with a functional programming language before.

@@nickchapsas I wouldn't make any assumptions yet. The solution you provide is great, but there are many things that can be optimized in aesthetic way or performance wise. So it all depends on how much time you have and what problems you solve.

​@@MrAndrei4777 If using Option over null causes a performance issue then you shouldn't be using c# for the program. The overhead is very small but the gains in making your code more maintainable / less error prone are massive.

From a client perspective often you don't know whether the object can be null or not, so it forces you to either check the implementation (which might change internally anyway) or make an additional check. Now, when you have null references setup as errors and with something like Optional you know exactly in the contract if it can be empty.

Zenit Kovacevic Every reference Type can always be null, there is no need to check the implementation.

This is wrong. You cannot not handle None when you’re using Option. The code won’t compile. This is the difference, that you NEED to handle None or else the code won’t even build. There are no NREs