<div dir="ltr"><div dir="ltr">Em dom., 13 de jul. de 2025 às 17:32, Nikita Bobko <<a href="mailto:nikita.bobko@jetbrains.com">nikita.bobko@jetbrains.com</a>> escreveu:</div><div class="gmail_quote gmail_quote_container"><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Coroutines are not magical. Effectively, CPS-transformation slices<br>
suspend functions by their suspension points. And under layers of<br>
abstractions, kotlinx.coroutine still submits those slices to whatever<br>
thread by doing old and boring threadPool.submit().<br></blockquote><div><br></div><div>IIRC, integration 2 requires merging values bound to the continuation with values bound to the thread at each "resume" point and then provided to the coroutine. Is this not the domain of the transformer or scheduler? shouldn't this be implemented in that layer? This way, Kotlin would guarantee structural integrity -- there would be no way for the user to fail to satisfy runtime requirements. Proposals which require the user to "close" bindings remove from the platform the surety of structural integrity, requiring "checks" to be introduced at code paths meant to be blazing fast.</div></div><div><br></div><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div>Pedro Lamarão</div></div></div></div>