I'm building a library that uses co-routines and c...

# coroutines

[Joris PZ]

I'm building a library that uses co-routines and channels internally. As I see it, I have a number of options when designing my public API:

• Offer an API that exposes suspending functions (which in turn uses the internal Channel structure)
• Hide my co-routines completely, and offer a blocking API to the clients
• Provide two separate API classes (class XYZ and class BlockingXYZ?)
• Provide a single API class with both suspending and blocking versions of my methods, i.e. suspend fun doABC() and fun doABCBlocking()

Are any of these choices considered idiomatic? Or should I just do what feels right to me?

[arocnies]

Do you want your API to be usable from Java?

I've heard it said that suspending functions should be named normally suspend fun abc() and if you want to provide Futures/Promises/Deferreds you would name them fun abcAsync()

[Joris PZ]

Good point. No, Java interop isn't important in this case, though it's always nice to have of course.

[arocnies]

Personally, I like to provide API's with suspending functions. If I later need Java interop, I would wrap the suspending functions with an ___Async() function.