Skip to content
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

More support for ranges #3736

Closed
AlexCue987 opened this issue Oct 13, 2023 · 14 comments
Closed

More support for ranges #3736

AlexCue987 opened this issue Oct 13, 2023 · 14 comments
Assignees
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. enhancement ✨ Suggestions for adding new features or improving existing ones.

Comments

@AlexCue987
Copy link
Member

AlexCue987 commented Oct 13, 2023

Examples:

  • (0..2) shouldOverlapWith (1..3)
  • (2..3) shouldBeIn (1..4)
  • (0..1) shouldNotOverlapWith (2..3)
  • (4..5) shouldNotBeIn (1..3)

should support both ClosedRange and OpenEndRange.

I'd like to do it if this feature is needed.

@AlexCue987 AlexCue987 added the enhancement ✨ Suggestions for adding new features or improving existing ones. label Oct 13, 2023
@mirageoasis
Copy link
Contributor

I think add support shouldBeIn range would be hard. But maybe creating new function can be solution.

@AlexCue987
Copy link
Member Author

I think add support shouldBeIn range would be hard. But maybe creating new function can be solution.

got it. how about this (2..3) shouldBeInsideOf (1..4)

@mirageoasis
Copy link
Contributor

I think add support shouldBeIn range would be hard. But maybe creating new function can be solution.

got it. how about this (2..3) shouldBeInsideOf (1..4)

think we have to specify which type we should accept only range? or other list types

@mirageoasis
Copy link
Contributor

if maintainer says yes maybe I can add method to support this proposal

@AlexCue987
Copy link
Member Author

I think add support shouldBeIn range would be hard. But maybe creating new function can be solution.

got it. how about this (2..3) shouldBeInsideOf (1..4)

think we have to specify which type we should accept only range? or other list types

only ranges. It does not make sense for lists

@sksamuel
Copy link
Member

What about

(0..2) shouldIntersect (1..3)
(2..3) shouldBeWithin (1..4)

@sksamuel sksamuel added the assertions 🔍 Related to the assertion mechanisms within the testing framework. label Nov 12, 2023
@AlexCue987
Copy link
Member Author

What about

(0..2) shouldIntersect (1..3)
(2..3) shouldBeWithin (1..4)

let's use these function names

@sksamuel
Copy link
Member

Assigned to you

@mirageoasis
Copy link
Contributor

I think there should be some careful approaches about ranges since it has backward range

@mirageoasis
Copy link
Contributor

mirageoasis commented Nov 13, 2023

I think there should be some careful approaches about ranges since it has backward range

and think we need to add support for until
or maybe can I get until feature assigned?

@sksamuel
Copy link
Member

I think there should be some careful approaches about ranges since it has backward range

backwards or forwards, still comprises a set of numbers, so within should be fine.

@LeoColman
Copy link
Member

I'd also enforce that we should try to go for an strictly correct mathematical definition.

Sets theory is very well defined, ie

  • A set within a set
  • An open ended range
  • A close ended
  • etc

@sksamuel
Copy link
Member

I will release 5.8.1 from what is on main in a few days, then whatever comes after will move to 5.9 which is will be kotlin 1.9+

@AlexCue987
Copy link
Member Author

implemented only intersect #3792

@LeoColman LeoColman linked a pull request Mar 9, 2024 that will close this issue
LeoColman added a commit that referenced this issue Mar 9, 2024
Linked: #3736 

Co-authored-by: Leonardo Colman Lopes <dev@leonardo.colman.com.br>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
assertions 🔍 Related to the assertion mechanisms within the testing framework. enhancement ✨ Suggestions for adding new features or improving existing ones.
Projects
None yet
Development

No branches or pull requests

4 participants