Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Revert "Boundschecks for searchsorted & remove step(r::Range)==0 tests"
This reverts commit 10e51e5. Originally merged by 2d5dbf3, this is incorrect in a number of ways. The searchsorted* methods with explicit lo and hi indices are an not part of the public API for these functions. Thus, the correctness of the bounds given don't need to be checked – that is up to the caller. If we decide to expose the ability to call searchsorted* with explicit start and end indices, there should be a better API for that which doesn't require passing an Ordering object and which checks bounds. In particular, this broke the old behavior of searchsorted when the value that's being searched for is not in the array. Fix #7916. Also added somes tests to make sure this doesn't regress again. At the time this was committed, I think that ranges could actually have a zero step – there was a reason for that check to be there. This may no longer be the case, but since it's cheap to check, we may as well handle it correctly and decouple the correctness of the sorting functions from a detail of the range implementation. Conflicts: base/sort.jl
- Loading branch information
fda850b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One could argue that if this is not part of the public API, these functions should have a different name so that they aren't exported.
fda850b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One could argue that – and I have when I was talking about separating the internal and external parts of interfaces. However, at the moment we do this all over the place, so this is hardly the only offender. We need a more general solution to this, even if only a best practice to give the internal parts of functions a different name.
fda850b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
No, at that point ranges already couldn't have a step of zero. See
#7078 (comment)
fda850b
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, ok. Well, it still doesn't really hurt to check for that case, although I guess I could re-apply that part.