```interface RestApi { fun get() fun post() fun put() fun delete() } interface NewRe...

# coroutines

[Karthik Periasami]

interface RestApi {
    fun get()
    fun post()
    fun put()
    fun delete()
}
interface NewRestApi {
    suspend fun get()
    suspend fun post()
    suspend fun put()
    suspend fun delete()
}

I am adding a feature in my rest client library to support suspend functions. What is the recommended prefix for suspend method names? I need something to differentiate between the non-suspend functions, to avoid misunderstanding. Any ideas are welcome, I suck at naming.

[Francesc]

are the non-suspending functions blocking? if so, you could rename those to blockingXYZ as in blockingGet, blockingPost

[wasyl]

Distinguish them by package and let the users import the preferred version?

[Karthik Periasami]

I cannot rename the existing functions, as it might affect the current usage of the library.

I am currently differentiating this with different package, but the problem its not that straight forward in code reviews to find out which get is used.

[ephemient]

@JvmName("get") fun blockingGet() might help if you want to maintain binary compatibility with existing users (although this would be a source compatibility breakage)

[ephemient]

oh wait that might not work on interfaces

[ephemient]

interface RestApi {
    @Deprecated("Use blockingGet", ReplaceWith("blockingGet()"), DeprecationLevel.ERROR)
    fun get()
    @Suppress("DEPRECATION")
    fun blockingGet() = get()
}

will maintain ABI compatibility for existing users. new users use the new function name, and eventually you may be able to hide or remove the old function name

[TwoClocks]

I just used get and getSuspend. The getSuspend must be called from a async block, and depending on what get does the compiler can also warn you if your making blocking calls from async code.

[TwoClocks]

Or if the API is primarily intended to be called from async code I'll use getNoSuspend. But as far as I know there is no convention.

[ephemient]

1. the IDE only has a really dumb heuristic right now: if it's @Throws(IOException::class) it'll warn about calling from suspending context, if the dispatcher isn't known to be IO... many issues such as https://youtrack.jetbrains.com/issue/KTIJ-838 etc.
2. IMO, suspend fun getSuspend() is too much stutter

[ursus]

I saw people prefixing await. Also, I wouldn't put any notation on it, you cant call suspend function from a nonsuspending context anyways