[naasking]

Good review, but I frankly don't see the point of Result<T0, T1>. Just have the error be an exception type as exceptions idiomatically represents errors in .NET. Then you're down to only 1 type argument which is much less noisy. That's what I've used for the result type in my library that I've been using for years. I don't use it often, but it's very handy when appropriate.

[louthy]

If you ask yourself what the meaning of the word 'exception' is and then consider how many failures are exceptional, then one quickly realises that exceptions are the worst thing you could use to represent expected failure conditions.

The only time we should throw (or even pass around) exceptions is if there isn't a slot in the co-domain to inject a value in to.

[veleon]

I think OP means using Result<T> where Right in the Either is always implied to be Exception, much like Fin<A> in language-ext [0]

[0] https://louthy.github.io/language-ext/LanguageExt.Core/Monad...

[louthy]

I think you mean Left. And Left in Fin is Error, which has two subtypes: Expected and Exceptional, along with bespoke matching primitives for exceptional and non-exceptional errors (for the reasons I outlined)

I understood what they meant, Exception is still a poor type for declarative error handling, because it’s unclear whether an event is truly exceptional.

[naasking]

The dangers and pitfalls of exceptions are completely irrelevant if all you're doing is using an exception as a value and not for control flow.

[louthy]

It’s not about danger it’s about being declarative. That’s kinda the point of using these ‘result’ types: you’re fully declaring the codomain of the function — barring exceptions — and so if your codomain is augmented with Exception then it’s pretty hard to know whether all exceptions will be returned in value form, or just exceptional exceptions! It’s fails the declarative test.

[naasking]

It's not hard at all: a return type of Result is when it's returned in value form.