You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Have you ever thought about incorporating an option monad into Dotnet? While C# may not be inherently a functional language, expecting it to be a built-in structure might be unrealistic. Nevertheless, given the prevalence of using option monads to manage null values, I believe it would be beneficial to have a built-in option monad in some capacity within Dotnet.
There are probably valid reasons why Option and Maybe monads don't have their place in C# at this time. Mainly because C# code uses null a lot. It's a much faster abstraction, but it is completely different from Option.
Option models the concept of something or nothing, explicitly. These are the two only valid options.
With null on the other hand, you can possibly get it as a third state, depending on underlying implementation, assuming the whole idea is you want to write code that is exception-free.
Say your API returns T? to denote some or none. What if in your internal implementation to something, you use third party libraries or even framework code, integration code, etc., that can fail silently by returning null (maybe it handles exceptions and just returns null instead)?
Then it's no longer a valid API that you've written, from the perspective of its requirements, as the none result is not actually a valid none anymore, or at least in all possible cases, but a swallowed error.
What I prefer to do is model with nullable reference types in places where I have absolute control over all dependencies, and none of them call code I did not write, because this way the code is much leaner and faster.
Otherwise I would use https://dotnet.github.io/dotNext/api/DotNext.Optional-1.html even if it adds some extra memory allocations, because it's generally worth it, so I can write safer code. DotNext's Optional type also supports nullable reference types and exposes that third option to you, using a getter (i.e. is-none and is-null are treated separately).
Have you ever thought about incorporating an option monad into Dotnet? While C# may not be inherently a functional language, expecting it to be a built-in structure might be unrealistic. Nevertheless, given the prevalence of using option monads to manage null values, I believe it would be beneficial to have a built-in option monad in some capacity within Dotnet.
In case you don't know what am I talking about: https://www.pluralsight.com/tech-blog/maybe
Where is the proper place to ask for this feature? What if I wanted to contribute to the implementation?
The text was updated successfully, but these errors were encountered: