Is there any ongoing work on the Result type to make it more

Question

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 < elizarov>

Dico · Answer

The ability to use and operators on other types I think is the most interesting

Dico · Answer

I would like for there to be some kind of `operator fun isEmptyValue Boolean` or whatever

Dico · Answer

I dont think that works because the type needs to change as a result of the operators though

elizarov · Answer

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

jdemeulenaere · Answer

Thanks for the update slightly smiling face

Oleh Havrysh · Answer

< 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 lt T gt `

Oleh Havrysh · Answer

If more specifically there would be something like ``` fun CoroutineScope run params P ReceiveChannel lt Result lt T gt gt ``` So in that way I m gonna handle data and errors in `Presenter

elizarov · Answer

What do you mean by safely

Oleh Havrysh · Answer

I mean that if I use `Result` in my base architecture it will always be valid both `fun action Result` and `fun action Channel lt Result gt ` 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

Dico · Answer

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

elizarov · Answer

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