Monads in C# (Part 2): Result

Post by gr4vityWall » Mon, Jan 05, 2026, 12:00 PM UTC

douglasisshiny wrote: post #26

Roonerelli wrote: post #21

I've had the misfortune of working on a C# code base that uses this pattern for many years. I've also used it with F#, where it feels natural - because the language supports discriminated unions and has operators for binding, mapping etc. Without that, it feels like swimming against the tide. Code has a greater cognitive overhead when reading it for the first time. And there is always a big over head for new starters…

I felt the same way with fp-ts then effect in typescript. Pretty cool libraries and I learned a lot about FP while trying them out for a couple of years, but a lot of ceremony and noise due to them (especially effect) almost being a new language on top of typescript. Recently got the opportunity to try out elixir at my job and I'm liking it thus far, although it is an adjustment. That static typing and type inference…

Post by xnorswap » Mon, Jan 05, 2026, 12:18 PM UTC

fuzzy2 wrote: post #24

xnorswap wrote: post #10

I really dislike this pattern: try { id = int.Parse(inputId); } catch (Exception ex) when (ex is FormatException or OverflowException) { throw new InvalidOperationException("DeactivateUser failed at: parse id", ex); } Where all you're doing when you catch an exception is throwing it in a more generic way. You could just let the FormatException or OverflowException bubble up, so the parent can handle those differently…

Doing it like this (or preferably with a custom exception) translates the technical problem into a domain problem. Without doing this, callers can't properly handle it. FormatException or OverflowException could be thrown at multiple locations, not just in parsing the user ID. This here is an InvalidUserIdException. It could be derived from ArgumentException, but IMHO InvalidOperationException is not appropriate.

Post by epolanski » Mon, Jan 05, 2026, 1:04 PM UTC

mrkeen wrote: post #34

epolanski wrote: post #32

Earlier quoted context omitted.

Identity function returns the same _value_. If it's only the same _type_, but the value is not the same, then it's an endomorphism. The function definitions look the same `a -> a`. string reversal, integer negation or toUpperCase are classical examples of endomorphisms. Identity is a specific case of endomorphism.

string reversal, integer negation or toUpperCase are classical examples of functions which will not compile as `a -> a` The function which will compile as `a -> a` is the identity function.

Post by FrustratedMonky » Mon, Jan 05, 2026, 1:15 PM UTC

louthy wrote: post #27

This is all very basic, instead you can use C#'s new static interface methods feature to create higher-kinded traits where you can properly generalise over a monad trait (or applicatives, functors, foldables, etc.), which is what I do in language-ext [0]. I'm not saying that implementing SelectMany for specific data-types isn't valuable. It certainly ends up with more elegant and maintainable code, but the true power…

Post by louthy » Mon, Jan 05, 2026, 1:38 PM UTC

FrustratedMonky wrote: post #37

louthy wrote: post #27

This is all very basic, instead you can use C#'s new static interface methods feature to create higher-kinded traits where you can properly generalise over a monad trait (or applicatives, functors, foldables, etc.), which is what I do in language-ext [0]. I'm not saying that implementing SelectMany for specific data-types isn't valuable. It certainly ends up with more elegant and maintainable code, but the true power…

Serious question, at this point, have all F# features been fully incorporated into C#?

    public abstract record Either;
    public sealed record Left(L Value) : Either;
    public sealed record Right(R Value) : Either;