https://kotlinlang.org logo
#announcements
Title
# announcements
j

jdemeulenaere

06/25/2019, 4:58 PM
Is there any ongoing work on the Result type to make it more available without the current restrictions ? I'm mostly interested in having Result with the language improvements mentioned in the "integration into the language" section (https://github.com/Kotlin/KEEP/blob/master/proposals/stdlib/result.md#integration-into-the-language) @elizarov
d

Dico

06/25/2019, 5:29 PM
The ability to use !! and ? operators on other types I think is the most interesting
I would like for there to be some kind of
operator fun isEmptyValue(): Boolean
or whatever
I dont think that works because the type needs to change as a result of the operators though
e

elizarov

06/25/2019, 8:28 PM
There’ve been some design discussions but results are not satisfying so far in the sense that we failed to invent a consistent and clear set of rules to extend null-handling operators to the result class. They don’t look natural there. We’ve also discussed adding some new error-handling operator, but made no good progress on that front, too.
j

jdemeulenaere

06/26/2019, 10:14 AM
Thanks for the update 🙂
o

Oleh Havrysh

07/12/2019, 12:57 PM
@elizarov Am I right that
Result
could be safely used in my app after adding
-Xallow-result-return-type
? (If I don’t use !!, ? operators) Just want to create
BaseInteractor
for my architecture that would return
Result<T>
If more specifically, there would be something like
Copy code
fun CoroutineScope.run(params:P):ReceiveChannel<Result<T>>
So in that way I’m gonna handle data and errors in `Presenter’
e

elizarov

07/12/2019, 2:58 PM
What do you mean by “safely”?
o

Oleh Havrysh

07/15/2019, 8:09 AM
I mean that if I use
Result
in my base architecture, it will always be valid (both
fun action():Result
and
fun action():Channel<Result>
). That is, I want to be sure that in the next versions of Kotlin it will not be forbidden. In next versions of Kotlin
Result
will be usable for return type without
Xallow-result-return-type
flag, yes?
d

Dico

07/15/2019, 10:02 AM
The reason that result return type is not permitted by default is that it leaves more space to make the type better integrated into the language, without having to worry about backwards compatibility as much in the design of such feature. Therefore, it is not safe to assume that the behaviour will stay exactly the same.
e

elizarov

07/15/2019, 10:53 AM
The reason it requires a flag is that it’s future is not decided yet. Since there is not decision, it is not known what will happen in the next version. If we knew, it would have been allowed.
5 Views