A modern programming language that makes developers happier.

kotlinlang

Screenshot 2019-04-03 at 10.23.37.png

I just want to say thank you to whomever thought of this warning.

This is recommended convention for Kotlinx.corotuines

Just curious, what is yiour use case for returning UUID in Deferred

that’s an api call to get the UUID from an endpoint.  Converted the api calls to use coroutines by wrapping them in Deferred&lt;&gt;

<https://github.com/Kotlin/kotlinx.coroutines/blob/master/docs/composing-suspending-functions.md#async-style-functions>

this is part of Kotlinx.coroutines doc about this convention

&gt; that’s an api call to get the UUID from an endpoint.  Converted the api calls to use coroutines by wrapping them in Deferred&lt;&gt;
Why do you need Deferred in this case instead of suspend function?

<https://github.com/JakeWharton/retrofit2-kotlin-coroutines-adapter>

Soon retrofit will support suspend functions

I’m looking forward to that, but for now I’m happy with this pattern

not the point I was trying to make when I uploaded that image

for now I would just suppress this warning for retrofit interfaces and refactor Deferred to suspend functions later

I just like it that the IDE picks up on naming conventions because I know it’s easy to miss those.

Yeah, but I wouldn’t use this convention for retrofit services if you use them directly, without wrapper, because soon you will probably refactor it

Well, ironically, as <@U0BRK9HC5> mentioned, this is the exact case where it's better to ignore this warning and not follow the convetion. Because you'll replace it soon, the `suspend` support is already in the retrofit snapshot

Thanks for the advice :slightly_smiling_face:

though they way I did it, once the suspend function is supported, it’ll be really easy to just remove the Deferred&lt;&gt; wrapper and still make the call through the same coroutinescope and things I set up :thinking_face:

if you use them always as `api.getUuid().await()` that it will be easy and exactly the same in terms of scopes, lifecycle, dispatchers etc, just remove `Deferred&lt;&gt;`, remove `.await()`and add `suspend`

True, but the `Async` in the name will be redundant and that was the premise of this thread.

I found using async named functions make sense only when it launches multiple tasks concurrently over one after the other.

<@UCQSRLA2J> Hm, what do you mean? Async named functions make sense only if it returns Deferred, if it suspend function and under the hood it launches multiple tasks (you can do this using coroutineScope/withContext functions), than no need to use Asyn in name, because it’s just an implementation detail

<@U0BRK9HC5> Yeah, i meant the ones that return Deferred. Caller can leverage concurrency by fun downloadImageAsync : Deferred&lt;T&gt; vs suspend fun downloadImage

Yeah, correct, for such case. But I usually don't see a reason for such functions in public API, more flexible provide suspend function and a user of this API easily can wrap it to Deferred on call site if some concurrency is required