Jake Wharton

Moreover, if there's a need to cast it means you're actually changing the type which would otherwise be inferred to something else.

Right so I have used this library before and recall the problem. It uses a recursive generic which is something you really only want to do on an abstract base...

I also think `having` pairs well with `extracting`, should we opt not to change it to something like `eachHaving`.

Seems like the main artifact should be the JVM jar with the Gradle module metadata. Then the common artifact is a separate artifact ID, like how the stdlib works.

Yeah I chose "has" because I thought Truth used it pervasively, but it seems like they use it in quite limited fashion. The ones I use _constantly_ are `ThrowableSubject.hasMessageThat` and...

`prop` is also an extension. I think its implementation APIs (`transform` and `appendName`) are both public so it probably could just be made `inline` so that it works in both...

We're already renaming the functions and breaking everyone. The deprecation replace with for both `prop` and `suspendCall` can both target the new, single function.

Indeed Kotlin doesn't use the same name, although I also don't think that's a strong design decision on their part. `map` is basically forced on them, and `let` seems more...

I don't think they should be combined. One is a general assertion which refines the type, whereas the other is an assertion on the contents of a collection.

That assertion is impossible to otherwise represent though. It requires #450. Asserting not null or empty is worded as `not(null or empty)` but that is logically equivalent to `not(null) and...