first class support for Array and Sequence in api-fluent

[robstoll]

Platform (jvm, js, android):
Extension (none, kotlin 1.3, jdk8): none

Code related feature

Currently one has to convert an Array or a Sequence to List or Iterable in order to be able to use the corresponding assertion functions such as contains. For instance

expect(arr).asList().contains(..)

We would like to be able to provide the same functionality (well almost the same, more details below) we provide for List to Array (all array types, see arrayAssertions.kt) and the same functionality we provide for Iterable for Sequence.

In detail, for Array:

• all functionality from iterableAssertions (and builder) without hasNext, hasNotNext
• all functionality from collectionAssertions
• all functionality from listAssertions

In detail, for Sequence:

• all functionality from iterableAssertions (and builder) without hasNext, hasNotNext
• isEmpty and isNotEmpty from collectionAssertions

I don't want to limit what approach is taken but it should be generative and please write down your idea here first so that we can discuss it before you start implementing things for nothing.
Note that your approach should be easily adoptable to the api-infix

---

Please react with 👍 if you would like to see Array and/or Sequence to be first-class citizens in Atrium, the more upvotes the more likely I will implement it myself -- feel free to sponsor me, that would be a motivation too.
You are of course welcome to work on this issue. Write I'll work on it as comment so that we can assign the task to you.

[robstoll]

I am currently refactoring IterableAssertions to IterableLikeAssertions, which means they can be used by Sequence or Array types on the logic level. Then there is only one step left to provide an API for Array etc. as well.

[robstoll]

Since 0.13.0, you can now pass Sequence and Array types to places where we expected Iterable so far. For instance to containsElementsOf(...)

[jakubriegel]

@robstoll is this still relevant?

[robstoll]

@jakubriegel it still is in the sense of that one has to write the following

expect(sequenceOf(...)).asList().toContain... // or
expect(sequenceOf(...).toList()).toContain..

or

expect(sequenceOf(...)).asIterable().toContain // or
expect(sequenceOf(...).asIterable()).toContain

instead of

expect(seqquenceOf(...)).toContain

As we can see from the votes, this is not really something people are bothered with that much because there is a good workaround I guess (if you disagree, then please up-vote this issue with a 👍 reaction on the description).
Nevertheless, if you would like to tackle it, then go ahead. Think about a possible solution and outline it before you start implementing it