btw, was it introduced for a specific case? Maybe coroutines related. Or just for generic purposes?

# android

[ghedeon]

btw, was it introduced for a specific case? Maybe coroutines related. Or just for generic purposes?

[gildor]

It's complicated question to be honest :)

[Mehdi]

I'd say it is good for generics.

[Mehdi]

but I won't know the real reason, since I am not a Kontributor yet

[gildor]

Because it called now Result (not SuccessOrFailure as before) and in package kotlin (so doesn't require import)

[gildor]

It's generic usage

[gildor]

But original proposal has very limited use case

[gildor]

But even now it's pretty limited to be compatible with future improvements (see Result keep for details)

[Mehdi]

@gildor do you consider that using a sealed class instead of the builtin Result useless ? because the builtin one already covers the use case?

[gildor]

What do you mean?

[gildor]

Sealed class is much more universal feature

[gildor]

And of course you can implement Result-like class with Sealed classes.

[gildor]

Result is inline class, so success state is free to use, doesn't require boxing on runtime

[Mehdi]

my bad, I thought the Result builtin was also a sealed class in the implementation. I just wanted to know if the use is justified if I want the Success and Error cases handled nicely

[gildor]

There is nothing magic in Result implementation, you can write own version using inline classes

[gildor]

But Result has some language level limitations that require for future improvements

[ghedeon]

@Mehdi answering your question, use your own class, because your case is domain specific. Also, from the Result KEEP:

NOTE: This Result class cannot be used directly as a return type of Kotlin functions. See limitations section for details.

[gildor]

You can use Result as return type, there is a special flag to enable it