The way suspend calls are shown in <#C063G2ZBF8V|>...

# coroutines

[louiscad]

The way suspend calls are shown in #C063G2ZBF8V is unacceptable:
1. It hinders readability by inserting an icon + space between the function name and the parentheses.
2. It doesn't work for functions that are called without a preceding whatever. or a trailing lambda argument (coroutineScope and collect on this example)
The suspend call gutter icon in IntelliJ IDEA and Android Studio is a lot easier to read, thanks to vertical alignment, and far more reliable.
Please, just stick to that.

Here's a related issue I submitted 10 months ago, but only pushbacks and no progress since then kodee grumpy

[Dmitry Khalanskiy [JB]]

I'm saying this not as a JetBrains employee, but as a fellow kotlinx.coroutines user: I have no idea what those icons (whether gutter or inline) are even for, I'm never looking at them. I can imagine the use case of searching for function calls that look like they could be blocking but aren't suspend, but in that case, inline icons are better than gutter icons: if there is a blocking call on the same line as a suspend call, I won't accidentally skip looking at it. Could you share some advice on how to get something useful out of these icons?

[louiscad]

To me, these icons are important because a suspend call means the thread is no longer blocked, and stuff can happen to shared objects while the coroutine is suspended.

Depending on the code, it helps to know if I can assume a property stayed unchanged, or might have been touched by something.

It also helps me know where the code can stop executing based on external cancellation.

Basically, suspension points are synchronicity separators.

It's hard to find a short way to explain it for, say, a gutter icon tooltip, but those icons are important since we don't have it like Swift's explicit await prefix keywords (BTW, they're mandatory, unless you use let async, asynchronous tasks can't be started by mistake, the code won't compile unless you explictly choose between sequential or async).

[Dmitry Khalanskiy [JB]]

Oh, ok, makes sense. In single-threaded scenarios, shared access to mutable state can only happen inside a suspension point, from the point of view of every coroutine. In multi-threaded scenarios, this approach won't work, though.

[louiscad]

Who makes single-thread Kotlin apps, apart from Kotlin/JS developers?

[Dmitry Khalanskiy [JB]]

Every Android developer has a single-threaded subset of code (Dispatchers.Main users), so gutter icons should help with tracking state that only the main thread has access to.

[louiscad]

I'm really not a fan of inline icons because I need to scan the whole line to spot them. I want code reading to be fast.

I prefer gutter icons, just one line to scan (less eye movement required), and I'd also be happy to have the option to have suspend function calls display with specific color, kinda like @Composable functions that are in bright-ish green (for light color scheme), those would also be fairly easy to spot without focusing on every part of every single line one wants to scan.

[louiscad]

I've been doing coroutines on Android since 2017, and I find the gutter icons very important, regardless of whether the code runs on just the main thread, or not. 🙂

[Dmitry Khalanskiy [JB]]

Depending on the code, it helps to know if I can assume a property stayed unchanged, or might have been touched by something.

But you can rely on gutter icons to tell you that only if the coroutines that have access to that property can't execute in parallel, right? Once more than one thread can touch the property, how can gutter icons still be helpful?

[louiscad]

Right, that works when you know the main/single thread is the only one supposed to touch a given thing.

It also helps to know that a system event delivered on the main thread could have happened, like a lifecycle state change, a further keystroke, whatever.

[ross_a]

To be fair I think "unacceptable" is more than a tad strong, and actually I like the preciseness of inline and the suggestion provided on the ticket of colouring the functions themselves

[louiscad]

I said "unacceptable" because it's also unreliable, did you skip that part, @ross_a?

[louiscad]

The inline icons could be an option. I personally really don't like how they affect the readability for me, and prefer gutter icons or special colors, but giving the choice is probably best.

[ross_a]

Sure, that sounds like a bug (is there a ticket for that?), but fleet is also early access

[ross_a]

So unacceptable is still hyperbolic

[louiscad]

I reported the issue almost a year ago, it's right in the original post, you can read the content, and the title, to begin with 🙂

Coroutines is one of Kotlin's top features, and also probably the least understood one, so IDE unreliability on one thing that can help people understand what is going on is a problem, especially when JetBrains says that Fleet is the KMP IDE of the future.

It's preview, and it's time it gets addressed, before it loses this early access label and more people get confused at coroutines because of Fleet bugs.

[ross_a]

Your ticket is titled "Missing suspend call icon _in the gutter_" and doesn't obviously/clearly point out your issue in point 2 from your original message.

Since they have indicated they do not wish to make the suspend icon appear in the gutter perhaps it is a good idea to raise a more addressable and less subjective issue that the inline suspend icon is also missing in places where the code may suspend.

[turansky]

Who makes single-thread Kotlin apps, apart from Kotlin/JS developers?

Web Workers works fine 😉
Especially with worker factories