A modern programming language that makes developers happier.

kotlinlang

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>)
<@U2E974ELT>

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

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.

Thanks for the update :slightly_smiling_face:

<@U2E974ELT> 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;`

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’

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?

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.

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.