Robert Stoll

Sure, I suggest you transform one method in CharSequenceToContainCheckerSamples and then create a draft PR so that I can already give you feedback before you continue with the rest. (please...

Looks all good :+1: Just to avoid confusion, you can tackle all TODOs of this issue. Just leave the other issues for other people. If no one should be interested...

@rohitverma007 are you still working on this?

As mentioned in the duplicated issue #1360 this closely relates to #724 and I think we should also provide a report option which allows to define if we show also...

> I think it would be worth having per-assertionCreator option to show expectations that hold. that's covered in #1342 > When the actual list has one element only, then there's...

we had this once for `feature` but dropped it because the performance win you get is most likely insignificant compared to test setup etc. readable tests and less overloads in...

#724 is related but not the same. there are already functions to modify the behaviour on an Expect level (all experimental): https://github.com/robstoll/atrium/blob/main/apis/fluent-en_GB/atrium-api-fluent-en_GB/src/commonMain/kotlin/ch/tutteli/atrium/api/fluent/en_GB/expectExtensions.kt but we don't provide it at arbitrary places....

Maybe some more context: - you can currently exchange the `Reporter` where the default `Reporter` only reports failing expectations - `AssertionFormatter` decide how an `Assertion` is formatted in the output...

> Feature-level things (e.g. nested expect that changes subject) are not much different from RootExpect. I agree in terms of creating expectations but not in terms of reporting. Do you...

good point, I basically do the same, switch to group syntax as soon as I state more than one expectation. We already have (the experimental) API: ``` expect(foo) .withOptions {...