Is this something Kotest would be interested in? <...
# kotest-contributors
s
s
I'm reluctant to add new specs since we already have 10, and probably 3/4 too many. Could this be added to existing specs without breaking any users code?
s
I've asked before about
suspend
constructors 😜 I'm not entirely sure where it landed, I think it can be added without breaking binary. Not 100% on semantics
s
I remember the discussion, it was because you want suspendable extensions
s
There might be a slight change in order of initialisation.. 🤔 Yes, exactly
It's still about that 😂
s
I remember we looked into it in quite some depth
s
Either that, or I think I'm going to end up just going
runBlocking
route..
s
It might not be the end of the world to make SuspendFreeSpec or something ?
So its clear its the same thing, just with a suspendable body
Make a new version of each one, with the prefix Suspend
s
I'm still curious if we cannot fix it without breaking semantics, and binary. I vaguely remember you mentioned you might consider it across a major version.. I need to dig up the conversation
s
Yeah I would consider it for 6.0
My goal is that 6.0 lines up with when compiler plugins go stable, so we can build on them properly to allow you to run a single test in intellij for js and native. But right now they are breaking things too quickly to rely on compiler plugins anymore than we do.
I wonder if we could just change FunSpec (for example) to this:
Copy code
abstract class FunSpec(body: suspend FunSpec.() -> Unit = {}) : DslDrivenSpec(), FunSpecRootScope {
   init {
      runBlocking { body() }
   }
}
I cannot remember why we said this would change semantics
s
I think I mentioned something to avoid
runBlocking
, but I don't know how much it matters in regard to how everything is initialised.
Copy code
abstract class FunSpec(body: suspend FunSpec.() -> Unit = {}) : DslDrivenSpec(), FunSpecRootScope {
}
Where it's created:
Copy code
FunSpec().apply(body)
s
ah runBlocking doesn't exist on JS of course
I think the issue was that in JS we don't have a promise at the time the instance is created.
Was the other problem that
FunSpec().apply(body)
runs the body after subclass inits, and right now the superclass init gets priority.
s
Aha, yes that was the problem indeed