Allowing or like constructs (with the exception of isAnyOf which is or-like) only in filter, find etc. means we need a way to track that. Same goes for a not expression in such contexts. If we want to control this during compile time, then we have to introduce quite of complexity and I guess assertion functions would then look more like:
fun <E, T : Iterable<E>, Z: Expect<T>> Exp.hasNext() : Z = ...
instead of
fun <E, T : Iterable<E>> Expect<T>.hasNext() = ...
The first version would certainly be too complex for a lot of people which means writing own assertion functions would be come too hard.
However, an or like structure will most likely pop up as feature request for filter, find etc.
Thus: maybe we don't provide filter, find and the like as shortcut and one has to write it as
expect(listOf(1, 2, 3, 4, 8))
.feature("it > 4 && it < 10 || it == 3") {s -> s.filter { it > 4 && it < 10 || it == 3 } }
.containsExactly(3, 8)
which means one has to provide a description which fits on its own.
We could still add filter as shortcut though as follows:
expect(listOf(1, 2, 3, 4, 8)).filter("it > 4 && it < 10 || it == 3") { it > 4 && it < 10 || it == 3 }
So that one at least does not have to write feature but honestly, I have never used filter in a test myself and I am not so sure if this is really something which deserves an own shortcut.
A compiler plugin might help here, one more use case next to #20
Allowing
or
like constructs (with the exception of isAnyOf which is or-like) only infilter
,find
etc. means we need a way to track that. Same goes for anot
expression in such contexts. If we want to control this during compile time, then we have to introduce quite of complexity and I guess assertion functions would then look more like:instead of
The first version would certainly be too complex for a lot of people which means writing own assertion functions would be come too hard.
However, an
or
like structure will most likely pop up as feature request forfilter
,find
etc. Thus: maybe we don't providefilter
,find
and the like as shortcut and one has to write it aswhich means one has to provide a description which fits on its own. We could still add
filter
as shortcut though as follows:So that one at least does not have to write
feature
but honestly, I have never usedfilter
in a test myself and I am not so sure if this is really something which deserves an own shortcut.A compiler plugin might help here, one more use case next to #20