Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Build in option monad for dotnet core #1421

Open
desmati opened this issue Nov 30, 2023 · 1 comment
Open

Build in option monad for dotnet core #1421

desmati opened this issue Nov 30, 2023 · 1 comment

Comments

@desmati
Copy link

desmati commented Nov 30, 2023

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?

@brokenthorn
Copy link

brokenthorn commented Apr 10, 2024

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).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants