https://kotlinlang.org logo
Title
g

ghedeon

01/16/2019, 12:24 PM
btw, was it introduced for a specific case? Maybe coroutines related. Or just for generic purposes?
g

gildor

01/16/2019, 12:25 PM
It's complicated question to be honest :)
m

Mehdi

01/16/2019, 12:25 PM
I'd say it is good for generics.
but I won't know the real reason, since I am not a Kontributor yet
g

gildor

01/16/2019, 12:25 PM
Because it called now Result (not SuccessOrFailure as before) and in package kotlin (so doesn't require import)
It's generic usage
But original proposal has very limited use case
But even now it's pretty limited to be compatible with future improvements (see Result keep for details)
m

Mehdi

01/16/2019, 12:33 PM
@gildor do you consider that using a sealed class instead of the builtin Result useless ? because the builtin one already covers the use case?
g

gildor

01/16/2019, 12:36 PM
What do you mean?
Sealed class is much more universal feature
And of course you can implement Result-like class with Sealed classes.
Result is inline class, so success state is free to use, doesn't require boxing on runtime
m

Mehdi

01/16/2019, 12:39 PM
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
g

gildor

01/16/2019, 1:05 PM
There is nothing magic in Result implementation, you can write own version using inline classes
But Result has some language level limitations that require for future improvements
g

ghedeon

01/16/2019, 3:50 PM
@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.
g

gildor

01/16/2019, 4:25 PM
You can use Result as return type, there is a special flag to enable it