Add checks that the endpoints of partial ranges are not-NaN. #33378
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
|
[This needs tests before it lands] |
lorentey
approved these changes
Aug 8, 2020
|
@swift-ci please test |
|
Build failed |
|
Build failed |
|
@swift-ci test |
|
Build failed |
|
Build failed |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
We can't actually check for NaN (because the notion doesn't exist for Comparable), but we can require that the endpoint is non-exceptional by checking if it equals itself.
This will introduce a little bit of overhead for types that have non-trivial conformances to Comparable, but no worse than the check for creating a bounded range, so that should be acceptable (and it should be optimized away in concrete contexts, and it won't be noticed for the types where performance matters most).
Also updated the wording of the error message on the check for bounded ranges, to correctly reflect the actual condition being enforced when one of the endpoints is exceptional.
Addresses an issue that I noted on this SE thread: https://forums.swift.org/t/add-a-clamp-function-to-algorithm-swift/5405/45