:mega: :mega: :mega: `kotlinx.coroutines` version ...

# coroutines

[elizarov]

📣 📣 📣 kotlinx.coroutines version 0.20 for Kotlin 1.2.0 with sequence-like extensions for channels, improvements to parent-child relations, more Android support and fixes. See full changes here: https://github.com/Kotlin/kotlinx.coroutines/releases/tag/0.20

[koufa]

Wow the new features with parent etc are exactly what I needed when I was asking the questions some messages above. Well done. Do you have an estimation when will be the 1.0 release?

[elizarov]

We don’t share calendar plans to avoid expectations. It’s done when it’s done.

[koufa]

Ok fair enough! 🙂

[elizarov]

We threat kotlinx.coroutines as a serious production-ready library, though, maintaining binary backwards compatibility and writing lots of tests.

[elizarov]

Version 1.0 would not magically make it way better than it is now 🙂

[elizarov]

I can definitely say that kotlinx.coroutines will not become 1.0 until coroutines are finalized in Kotlin (language), which is currently tentatively planned for Kotlin 1.3 release.

[koufa]

Thank you for your detailed answer. I understand that the current state is production ready I can confirm it myself having tested it using it in a project. The api is very clear and well done, that you don’t expect from something that has the experimental flag. Unfortunately the only thing that will get better with 1.0 is the 3rd party support. For example in the Android space Retrofit, Room etc probably will have coroutine APIs then

[elizarov]

They are gradually introducing support even for experimental coroutines, which is the right choice. Coroutines are a game-changer for any library with asynchronous APIs.

[pdvrieze]

Looking at it, it seems to me that serialization of coroutines (as well as lambda's/closures) would be an important (perhaps optional) feature. I am not sure that it can be added in a binary compatible way, so it is something to consider. Perhaps integrating with the serialization library (and those efforts).

[elizarov]

It is a hard feature too, design-wise.

[pdvrieze]

Indeed. It is hard. coroutines even harder than lambda's. I've been thinking about it. You would probably need to somehow make things configurable. Perhaps all that is needed is a "SerializableContinuation" (and appropriate methods) where the user will need to plug in a "serializationStrategy". The compiler will just help by being able to feed it all the fields added to the coroutine (being passed a KSerializer).

[pdvrieze]

The compiler could also error/warn when some fields have no serializer defined (internal or external) - obviously not for primitives.