This sort of relates to #204 a bit.

Thanks very much for all the detail. I was intrigued when you mentioned using extension methods like this, so it's sad to hear that they don't quite work as is.

One initial question to buy me time to think about this more: In this particular case, how much does it help to put compressWhitespaces() on String instead of StringSubject? That of course doesn't help with the ignoreCase() use case, where you have to transform both the expected value and the actual -- and maybe you need to transform both values here, too?

(I'm wondering if this is going to lead us to create a separate ExtensionMethods class that provides the access you need.)

I need to transform both values, so the API wouldn't be nice if compressWhitespaces() is on the String. My goal was also that people type assertThat(string). and get a list of all options with auto-complete to improve discoverability.

Copying some internal discussion and thoughts. I was actually writing some Kotlin Truth subjects just as this issue got posted, so I had a couple.

I think @cgruber is right that the linked issue, about reorganizing subjects, would help. Having isEqualTo on Subject definitely kind of bakes in an assumption that there's exactly one Subject per type, and they'll all e.g. have the same notion of equality.

I'd personally be hesitant to expose actual() directly, but I could see providing a method on Subject that makes it possible for an extension function to return a new or modified Subject. I find myself wondering about exposing something that derives a new Subject from the existing actual value, preserving existing metadata about failure. But there's already an API that accepts a value and metadata about failure, and returns a Subject about that value -- it's Subject.Factory. So maybe some API accepting a "continuation" Subject.Factory...?

To be clear, writing vanilla Subjects in Kotlin is quite doable and pleasant, and the ability to have top-level assertThat is nice. But you can't really write useful extension functions on Subjects with the current API (other than those which just completely delegate to another assertion). That includes both terminal assertions and nonterminal extensions which have to propagate information.

Shall we merge this with #404?

Let's keep this one open, since it's more about extension methods. I just closed #404 along with the other requests for Predicate-accepting assertion methods. I'll update the title of this one to be more specific.

Two notes:

• We're going to somewhat regress here in the next couple Truth releases as we remove actual(). I've been assuming that you can reflectively access private Object actual just as well as you can access protected A actual(), though I grant that the private access is a little dirtier, since it could theoretically be removed or renamed at any time. We don't intend to remove it without providing you with something better (or remove it ever, in all likelihood, but no promises on that :)). Let me know if that will be a big problem, and we can look into expediting some other solution.

• We might like something like "Make creating error messages possible without extending Subject" / SubjectProtectedMethods inside Truth itself for IterableSubject.UsingCorrespondence (especially now that it's a static class for weird Java-7-compatibility reasons). However, I haven't thought this through.

I admit to some anxiety about relying on reflective access, but I can see why you're doing it. I would suggest that in the process, that reflective access actually be through a utility which has a consistent API, to avoid having subject implementers rolling their own reflection, and insulating internal changes a bit.

Agreed, we should provide a non-reflective API for this. (We should be able to avoid reflection even in the implementation, since there's still a package-private actual field on Subject, not private as I'd claimed above.)

Running into this issue (somewhat). My use case is also very similar:

I need to assert that certain lines of a multi-line string (coming from an existing subject chain) starting with a specific token, end with another token

Something like:

assertThat(gradleBuild()) // 3rd party truth extension
  .output() // multi line sting -> StringSubject
  .lines() // extension I want to add -> 'LinesSubject'
  .startingWith("my-start-token") // Filtered 'LinesSubject'
  .endsWith(expected)