The New Option and Result Types of C#

Hello, everybody. I'm Nick, and in this video, I will talk about the Result and Option types that C# might be getting in the future when Type Unions eventually release.

Don't forget to comment, like and subscribe :)

Social Media:

#csharp #dotnet

[Crozz]

I'm so happy you emphasize so much the importance of exhaustiveness and forcing yourself to handle all cases.

[alexclark]

'bout time C# grew a pair of monads

[mistrzmatik]

Me: Nick, can I use Rust?
Nick: We have Rust in C#
Rust in C#:

[michaeldileo]

One tip with LanguageExt options, you can switch on the Case property:
Option.Case switch { User u => …, null/_ => … }

[Sayuri]

All I can say is, I love when features become part of the C# standard rather than a Nuget package. Better visibility, better documentation, guaranteed bug fixes and security fixes. So much good stuff. And I do so agree 100% with everything you said in this video.

[patrickkurmann]

I've widely used the C# Functional Extension by Vladimir Khorikov for years, which implemented just that. I am glad it now becoms part of C#.

[joga_bonito_aro]

Returning result objects was one of the best things I ever did to my codebase.

[Masterrunescapeer]

5:15 "Exceptions are incredibly, painfully slow"
-> Jon Skeet, "If you ever get to the point where exceptions are significantly hurting your performance, you have problems in terms of your use of exceptions beyond just the performance."
Would argue those cases should often just be TryGet or something along those lines if normal logic of possible that does not exist.

[chrismantonuk]

I add a Result<T> with Succeeded, Error, Result properties to almost every project I work on, for this very reason. It works well but doesn’t enforce error path handling, so this is a great feature, very welcome. Will save lots of boilerplate.

[deeplerg]

Nick is gonna milk this proposal for 10 more videos

[joshman]

I do a lot of automation work, and I grew to love this feature in F#. It is definitely nice knowing you have handled every possible scenario in some way that will never fail.

[weicco]

I've written my own Result, Result<T> and Option<T> classes with Monad support. They work like charm. Plus they do away all null ref exceptions since you cannot write "null" anywhere 😂

Next I'm planning to write like virtual machine upon NET virtual (a bit hard to explain) so I can alter the values like in Unity game engine plus with diagnostic support.

After that I'm going to write my own programming language, compiler and virtual machine 😂

Edit. Ah, yes. I'm planning to write library so that you can use Monads in Controllers out of the box.

[Kotz_en]

Result type is great, but I don't really see the how Option<T> would be better than Nullable<T> in modern C# projects, where NRT is enabled (and especially if you have warnings as errors). It's essentially solving the same problem. In projects without NRT however, I do see the benefit.

[VitalMiguel]

I introduced functional programming in a big company and I must say I really enjoyed working with options result, pattern matching, unions etc. But it takes some time to learn and to read some chaining code when you have a lot of I/O calls. New developers feedback was always this, they enjoy it but they find it hard to understand this new way of thinking.
We only had a single bug in production in 3 years that didn't even affect users. It was on cache serialization of a model.
Option, Result and enforcing developers to only access the value through pattern matching is the way for no bugs, because 99% of it is when someone forgot to handle a exceptional path on code.
We want to achieve that "if it compiles it works" and this helps.
I'm also very happy with the introduction of this and see the feedback of devs and next moves.

[Hawkeyes]

This is perfect timing on this video for me! I am scheduled to give a Tech Talk on this topic next Thursday and had already watched your previous video from a year ago covering the Result Type. Needless to say I'm excited about this feature and have been enjoying using a home rolled version based on your example from the first video. Thanks Nick and keep up the great work!

[NickSteffen]

I think the most exciting part about this would be having analyzer support for ensuring all outcomes of a result or option type are handled when returned and seeing some of the older BCL library functions start returning result objects so that if you do use these objects you can link in and return them all the way up the chain. Something even cooler would be having the code analyzer tell you when a result type for an encompassing function doesn't include an error from one of it's sub types.

[Raminiya]

I think this is a very useful addition. It's also very useful to standardize other methods of error returns such as methods that return -1 in case of error for positive integer results or methods that return and array or list and reserve one field for an error. I hope it will also support the case when there is a result and a warning at the same time.

[Artokieffer]

It's nice to finally see that Microsoft wants to add Discriminated Unions officially in C#. I found them very neat last year when trying them in Rust for the first time, and I have been very tempted to use them with third-party libraries before, but I never took the plunge. Now that I know it will (hopefully) come in a future C# release, I can't wait to use them.

In any case, I think it's a step in the right direction because it will force developers to think ahead in order to handle all possibilities that their program could encounter.

[Sameer.Trivedi]

At this point you C# has enough things to recreate the entire Earth from scratch.

[bbqchickenrobot]

So excited foe the Result<T> and Option<T> - Now if we can get immutable variables by default!