<@U2E974ELT> re Result type. It wasn't that it did...

# stdlib

[dmcg]

@elizarov re Result type. It wasn't that it didn't open, just that I expected some sort of Algebraic data type, sealed class hierarchy.

[elizarov]

That particular proposal was specifically designed in encapsulated fashion, so that implementation details are not public and can be optimized. For application where efficiency is not of a paramount importance, you can always roll your own sealed class — it just takes a few lines of code.

[natpryce]

I’d want a Result type not to have a get() method that throws.

Also I’d want Result to be parameterised by the error type, so that I can type check error handling / conversion at the boundaries of bounded contexts. So the error might be an exception, or an enum or an instance of a sealed class hierarchy.

[elizarov]

Parametrization by the error type is definitely out of the scope of Kotlin stdlib, because that flies contrary to the conceptual approach to exceptions in Kotlin and there is no place it can be used by stdlib itself or other Kotlin-related libraries (Kotlin stdlib uses nullable types for that purpose). If you want a type that represents either a result or some application-specific kind of error, then I’d suggest using some kind of Either type for that. It is easy to roll your own with a sealed class.

[elizarov]

The name Result is specifically reserved to represent “_result_ of execution of a Kotlin function” which is, by definition of Kotlin language, is either a declared result of the corresponding function or a Throwable. E.g., in Kotlin a result of function declared with fun X(): T is actually Either<Throwable,T>, and code blocks in Kotlin correspond to do-notation on the corresponding monad.

[natpryce]

But this is an alternative to exceptions to support type safety, and so should not be limited by how kotlin implements exceptions.

[natpryce]

If Result doesn’t type-check the error cases, what’s the point of it? One might as well just use return values and exceptions.

[dmcg]

A good discussion, I wonder if it can be had more publicly?

Arguing that we can roll our own Either type doesn't help interoperability at all - which was where I started. Maybe if the stdlib needs this for its own purposes there is a need for both this Result and another ADT.

I'm wary of an approach that requires me to create an exception (an expensive process if one hasn't naturally occurred) just to signal failure from a function.

[elizarov]

The point of Result is described in the corresponding issue https://youtrack.jetbrains.com/issue/KT-18608

[elizarov]

You should NOT use exeptions to signal an error condition that should be handled by direct invokers of the function. This is bad style (in Kotlin). Exceptions in Kotlin are designed for errors that are handled at a larger scope. For local error conditions you should consider using nullable types (for example when you are trying to find something and you need an indication that it wasn't found) or domain-specific sealed classes, when you particular domain calls for a variety of error condtitions that need different ways ti handle them.

[natpryce]

Exactly! So the get() method of Result should never throw.

[natpryce]

Either it should not exist

[natpryce]

Or Result should be parameterised by both value type and error type, and then get can be be defined for Result<T,T>

[dmcg]

If we use domain-specific sealed classes then there is no standard way to map over a series of operations from different providers. That's why we're asking for stdlib sealed classes, and are surprised to see the proposed Result type isn't them.

[natpryce]

I've put my implementation up on GitHub https://github.com/npryce/result4k

[natpryce]

And maven central

[natpryce]

For those who are interested

[dave]

Thanks @natpryce , although i for one am really hoping that something like this will make it's way into the Stdlib. We don't want to recreate the Scala problem where there are many versions of the same simple concept knocking about and everyone is relying on different incompatible versions...that's just bad for everyone.

[dmcg]

The implementation meets my expectations. But the name...

[yoavst]

https://github.com/kittinunf/Result

[natpryce]

I think the error side needn’t be constrained to be a type of Exception.

[natpryce]

@dmcg what’s up with the name? Would you prefer a name that is a K-based pun?