hi guys, `shouldBe` definition makes compiler to ...

# kotest

[Adam Firen]

hi guys, shouldBe definition makes compiler to accept 1234 shouldBe "1234". The reason for it is that the compiler will figure the common type of both arguments which is Object and use it in runtime. I am looking for a way to move the type check to compile-time. Something that will fail the compilation if types don't match.

[Javier]

You could do:

1234.shouldBe<Int, Int>("1234")

[Adam Firen]

makes sense, although I was hoping for a solution where I can tell the compiler to use the actual type of the this parameter

[Sam]

I was looking at the internal annotations that could help with this… if you could write

infix fun <T, U : T> @kotlin.internal.Exact T.shouldBe(expected: U?)

that would achieve what you’re asking for, but I don’t know if there could be valid scenarios it would rule out. Also it’s not possible because the annotation is internal.

[Javier]

That internal annotation will be there forever? Looks like that can be a great addition to kotest

[Adam Firen]

interesting, since it's internal I would assume it might become part of the public api in the future 🤞

[Javier]

Gonna ask in #compiler

[Emil Kantis]

It's a bit complicated. In most scenarios it is undesirable to compare different types, as you say.. and I made a PR for the Kotest intelliJ plugin to add an inspection when you do such comparisons. During that PR work, I added some exemptions for primitives. Comparing int to long should be fine, float to double, IntArray to LongArray, etc.

[Emil Kantis]

I think the Exact variant would get troubles with these types as well.. but perhaps that should be fine, and we could use something like shouldEqual for those cases