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

Don't swap Range bounds by default #352

Open
lukaseder opened this issue Jun 24, 2019 · 3 comments
Open

Don't swap Range bounds by default #352

lukaseder opened this issue Jun 24, 2019 · 3 comments

Comments

@lukaseder
Copy link
Member

Currently, when using the Range type, bounds are swapped by default, if they are not in order. This can be convenient occasionally, but incorrect in other cases. With the suggestion of supporting (partially) unbounded ranges (#350), swapping may become wrong.

We should introduce new API that allows for swapping explicitly (akin to SQL's BETWEEN SYMMETRIC) and stop swapping implicitly.

This is an incompatible change. We might not actually implement it.

@awnofwheat
Copy link

I'd like to fix this issue by creating a constructer for tuple2 so that users can choose whether to swap bounds by themselves.

@lukaseder
Copy link
Member Author

I'd like to fix this issue by creating a constructer for tuple2 so that users can choose whether to swap bounds by themselves.

Thanks for your suggestion. For the record, the PR is here: #384. I've rejected it mostly because it is not Tuple2's concern that one of its subtypes has a flaw. Let's not fix things by breaking other things or introducing unnecessary functionality.

You probably took inspiration by this sentence:

We should introduce new API that allows for swapping explicitly (akin to SQL's BETWEEN SYMMETRIC) and stop swapping implicitly.

This "new API" must be limited to Range, not affect Tuple2 in any way.

@awnofwheat
Copy link

Thank you for your reply. I will be careful next time

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants