No, not really. Languages that don’t really embrace such a type can usually never make its use ergonomic. Adding such a construct to C or Java would be “trivial” but its use would be exceedingly painful.
Here's an example of a result type in Kotlin implemented as a library monad. (the language is getting an official one but is currently less featureful than this lib)
You can use exception or Result depending on when it makes the most sense and this is the best of both worlds.
https://github.com/kittinunf/Result
That depends a lot on what you mean by "use". Pretty much every commonly used language would be able to define something that can hold one of two things and provide ways to determine which one is present and retrieve one of the two options, but comparatively few are going to be able to provide the same guards against accidental or intentional misuse that pattern matching gets you.
it's trivial in any language to define and use a Result<T, E> type.
No, not really. Languages that don’t really embrace such a type can usually never make its use ergonomic. Adding such a construct to C or Java would be “trivial” but its use would be exceedingly painful.
Here's an example of a result type in Kotlin implemented as a library monad. (the language is getting an official one but is currently less featureful than this lib)
You can use exception or Result depending on when it makes the most sense and this is the best of both worlds. https://github.com/kittinunf/Result
1 reply →
That depends a lot on what you mean by "use". Pretty much every commonly used language would be able to define something that can hold one of two things and provide ways to determine which one is present and retrieve one of the two options, but comparatively few are going to be able to provide the same guards against accidental or intentional misuse that pattern matching gets you.