Consider reimplementing in Kotlin (separate from any API changes) and adding KMP support

[cpovirk]

Note: This is separable from Kotlin-focused API additions (e.g., #572, #544, #536 (which could lead to much deeper changes in how people use Truth under Kotlin)) and from Kotlin-focused documentation (e.g., #661, #849).

We'd "just" be talking about replacing the implementation in a way that is invisible to Java and Kotlin users except for the new dependency on the Kotlin runtime. (We could choose to go further someday by making API changes or additions, either instead of or in addition to the work of this issue. But the first thing to think about is the mere introduction of Kotlin at all.)

This is something that we're going to be evaluating as we look at supporting our KMP users. While there are existing KMP assertion libraries, and while those libraries leverage Kotlin in their API design (e.g., by using extension functions), some of our users are working to convert their Java code to KMP Kotlin while keeping their existing tests with as few modifications as possible (in order to maximize chances that the tests catch any problems during the conversion). Support for those users would be the primary goal.

Would this cause problems?

My sense is that, since Truth is already not aiming to be dependency-free, the addition of the Kotlin standard library (which a growing number of users already depend on, anyway, similar to our other dependencies) is not a big barrier for users.

One potential problem for a small minority of users is that they already use Truth under other environments (such as GWT) that require Java source code. If we switch our source code to Kotlin, then they'd be stuck on the final Java release. That might be tolerable, given we completed the biggest outstanding Truth work (namely, merging Truth8 into Truth) earlier this year, so there are no large features on the horizon.

If you are reading this and you know of potential problems (or you know anyone else who might know), please let us know.