Robert Stoll

I would prefer that as well but... I can imagine that the compiler won't be able to infer it correctly. Have to check though

The following would be possible: ``` inline fun Expect Any?>.toThrow(): Expect = ExpectImpl.changeSubject(this).unreported { { runBlocking { it() } } }.toThrow() ``` But the usage is not so nice, as...

`runBlocking` basically runs where the `suspend { ... }` only defines a lambda. In your expectBlocking `runBlocking` does not run immediately as you define a lambda as well (you wrapped...

It's a nice idea but does not work out as Kotlin cannot be able to figure out which overload it should take if you write: ``` myExpect { doSomething() }...

> Kotlin does prefer the suspend expect over the T one (which it should since the suspend version is more specific You're basically right, that's the way it should be...

> but unfortunately it's not how the the current type inference system behaves must have been a glitch, it works now :tada:

> Great! So we got ourselves a solution? I think a basic idea at least. But the final implementation and test will show it, especially regarding other platforms than JVM....

I have pushed a new commit to the branch, seems `implementation` would work, did not get problems in intellij. Thus we should start with `implementation` and move to `api` in...

One way to go for JS: https://github.com/Kotlin/kotlinx.coroutines/issues/885

> added a simple (and dump) example I think that makes a good point, I don't see why one would want to do async operations within `expect`. If we want...