Consider unifying first-party, `prop`-based helper function names (like `jClass`, `toStringFun`)

[JakeWharton]

The current naming is mostly just the property name as the function name. There's kClass(), collection size()s, exception message().

This strategy doesn't work for toString() or hashCode(). They get "Fun" suffixes as toStringFun() and hashCodeFun(), respectively.

This ties in somewhat with #521, and it actually leans me towards that issue choosing "have" so that these could be "has"-prefixed.

assertThat(foo).hasKClass().isEqualTo(Foo::class)
assertThat(array).hasSize().isEqualTo(3)
assertThat(user).hasToString().isEqualTo("User[name=Alice]")

[grodin]

Once there's an agreement on how to resolve #521, happy to handle this

[evant]

There is a subtle distinction there, the 'has*' methods do an assertion themselves while the non-has methods can't fail on their own. One thing I'd want to avoid is someone doing assertThat(array).hasSize() by itself not realizing that it will never fail.

[grodin]

Perhaps "having" could help here, as it seems less like an assertion:

assertThat(list).havingSize()

feels less like a complete sentence.

[JakeWharton]

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

[grodin]

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

Perhaps that's a useful general principle for this kind of thing; a method named with a verb which isn't an assertion should use the continuous ("ing") form of the verb.

That's almost certainly a premature abstraction, and wrong in the details, but I thought it was worth noting down.