-
Notifications
You must be signed in to change notification settings - Fork 68
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Range assertions #119
Comments
Thanks for raising this, that would be a nice addition! A specific overload of either function should do it, but I'm not sure which function we should use.
I would go with the 2nd option, but if you want to implement it I'm fine with either :) |
Also add JVM support for backtick version
I've added Please let me know which one you'd prefer @MarkusAmshove and @igorwojda. I'll update my PR accordingly :) |
I'd vote for |
Same with me |
Signed-off-by: Kshitij09 <kshitijpatil98@gmail.com>
Added shouldNotBeInRange for ClosedRange MarkusAmshove#119
Add shouldBeInRange for ClosedRanges #119
I was thinking about adding range specific assertions.
First of all current
shouldContain
/shouldNotContain
may not be efficient as we are using generic inferable implementation withforEach
under the hood instead of range specificrange.first
andrange.last
properties(r1.first >= r2.first && r1.last <= r2.last)
Second, below generic iterable extensions seems to be a bit counter-intuitive because we are not treating ranges as mathematical sets https://en.wikipedia.org/wiki/Set_(mathematics) :
Maybe we should add more specific implementation for
shouldContain
/shouldNotContain
to Range related types (ClosedRange
children) 🤔 or optionally add range specifics extensionshouldBeInRange
/shouldNotBeInRange
The text was updated successfully, but these errors were encountered: