5 ms·

Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/ho

Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...

vips7L 4y ago
I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions. I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?
- SemanticStrengh 4y ago
  > Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember. I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..
- ackfoobar 4y ago
  > you still need to mark functions as suspend and only call suspending functions from other suspending functions. You restated the idea of function colouring without further elaborating why it is a problem. If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.
  - SemanticStrengh 4y ago
    runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types? If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.
    - ackfoobar 4y ago
      You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...
      - SemanticStrengh 4y ago
        Then you'll have to explain why that isn't the default main behavior then. Synchronous functions cannot call async functions (without defining N runblocking scopes) but a runblocking main would make kotlin seems color-less and should be seen as best practice. What's the catch?
        ackfoobar 4y ago
        > would make kotlin seems color-less Quoting the post: > Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. Also you can do `suspend fun main()`
  - vips7L 4y ago
    > You restated the idea of function colouring without further elaborating why it is a problem Did you not read my second paragraph?
    - ackfoobar 4y ago
      > I am also not sure It felt like a question more than a complaint. > create an interface that can be implemented by both suspending and synchronous functions If interface has a suspending method, the implementations will also be suspending. But you can choose not to make any suspend calls in the method body. Not being able to say "this particular implementation of a red interface is blue" has never bothered me.
      - vips7L 4y ago
        I guess my complaint is that it doesn’t work with object oriented programming. It’s the same reason why I don’t like checked exceptions, checked nulls, or Result types.

Here the Kotlin lead argued that it is not a "problem". https://elizarov.medium.com/how-do-you-color-your-functions-a6bb423d936d https://elizarov.medium.com/how-do-you-color-your-functions-...

vips7L 4y ago

I don't really see how that's not a problem. While not having to specifically await you still need to mark functions as suspend and only call suspending functions from other suspending functions. I am also not sure how this explicit marking would work with interfaces. Can you create an interface that can be implemented by both suspending and synchronous functions?

SemanticStrengh 4y ago
> Can you create an interface that can be implemented by both suspending and synchronous functions? I don't remember. I do know you can at least specify suspend in an interface method to enforce its implementers to be suspending too. Note that this is e.g impossible in typescript..
ackfoobar 4y ago
> you still need to mark functions as suspend and only call suspending functions from other suspending functions. You restated the idea of function colouring without further elaborating why it is a problem. If your thread can afford to block and want to call a suspend function, use `runBlocking`. If your thread cannot block, having `suspend` in the type just saves you from a bug.
- SemanticStrengh 4y ago
  runBlocking can't run regular functions right? Othwerwise what's preventing you from making the main() runblocking and have all functions under a context that allow both types? If runblocking can't allow non-suspending function then you got a problem because that mean a method implementing an interface can either be suspending or not and therefore for one of two implementation, fail.
  - ackfoobar 4y ago
    You can absolutely do this. `fun main() = runBlocking<Unit> {` https://kotlinlang.org/docs/composing-suspending-functions.html#async-style-functions https://kotlinlang.org/docs/composing-suspending-functions.h...
    - SemanticStrengh 4y ago
      Then you'll have to explain why that isn't the default main behavior then. Synchronous functions cannot call async functions (without defining N runblocking scopes) but a runblocking main would make kotlin seems color-less and should be seen as best practice. What's the catch?
      - ackfoobar 4y ago
        > would make kotlin seems color-less Quoting the post: > Having to mark asynchronous functions with suspend modifier is a small price to pay, but in return you get better insight into your code. Also you can do `suspend fun main()`
- vips7L 4y ago
  > You restated the idea of function colouring without further elaborating why it is a problem Did you not read my second paragraph?
  - ackfoobar 4y ago
    > I am also not sure It felt like a question more than a complaint. > create an interface that can be implemented by both suspending and synchronous functions If interface has a suspending method, the implementations will also be suspending. But you can choose not to make any suspend calls in the method body. Not being able to say "this particular implementation of a red interface is blue" has never bothered me.
    - vips7L 4y ago
      I guess my complaint is that it doesn’t work with object oriented programming. It’s the same reason why I don’t like checked exceptions, checked nulls, or Result types.