-
-
Notifications
You must be signed in to change notification settings - Fork 5.5k
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
RFC: Make empty ranges compare equal #32348
Conversation
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.
This is great, thank you! I did a cursory search for both 0:-1
and 1:0
literals in base and the stdlibs — some more candidates to examine include:
stdlib/Dates/test/ranges.jl
38: @test sortperm(dr) == 1:1:0
96: @test sortperm(dr) == 1:1:0
156: @test sortperm(dr) == 1:1:0
214: @test sortperm(dr) == 1:1:0
stdlib/REPL/test/replcompletions.jl
924: @test r == 1:0
The above tests should probably use ===
.
There are some cases where it is definitely necessary to check that the ranges as well as their startpoints are equal (like Edit: there is a precedent for using |
I just tentatively replaced all comparison between empty ranges by Test Failed at /home/sebastian/Development/julia/usr/share/julia/test/ranges.jl:1022
Expression: -r === mr
Evaluated: -1.0:26.0:-27.0 === -1.0:26.0:-27.0 So we could either say that In my opinion, it would suffice to change the comparison to |
I changed all tests that I found which compare empty ranges to use
Edit: Apparently some of the new Edit 2: To fix the tests on 32-bit systems, I used the |
Can you tell if the failures are related now or unrelated? |
The failures should be unrelated. |
The failures are on both Windows buildbots and both:
The AppVeyor build passed, so even if there's range-y things going on in the processing of those strings, I have a hard time rationalizing how this change would lead to that sort of buildbot-only failure. I'll try rebuilding the buildbots. Perhaps httpbin.org was in a strange way for a moment. |
Thanks, @mbauman! I just added a NEWS.md item. |
Indeed, this is a very impressive and greatly appreciated first PR. Thanks for sticking with it so long! |
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.
Lines 61 to 64 in 548b667
@test searchsorted(1:3, T(0)) ==ᵣ 1:0 | |
@test searchsorted(1:3, T(1)) == 1:1 | |
@test searchsorted(1:3, T(2)) == 2:2 | |
@test searchsorted(1:3, T(4)) ==ᵣ 4:3 |
Note that the need for ==ᵣ
in this case arises from the fact that the returntype of searchsorted
depends on the type of the value being searched. There is an issue for that: #32568. Once that is resolved, the searchsorted
tests can be changed to use ===
instead of ==ᵣ
.
Edit: All tests for empty ranges now use ===
.
@nanosoldier |
Your package evaluation job has completed - possible new issues were detected. A full report can be found here. cc @maleadt |
Essentially all the package test failures were due to transient download/connectivity errors. There's one, though that looks like a real failure: StrRegex.jl:
That sure looks like the result of comparing an empty range, but I can't find it directly in that package. |
The problem is The result of |
What is the state of this PR? There is one day left before feature freeze for 1.5, I'm willing to review and merge if it's ready. Or does it need to go through triage? |
I think the PR is ok, but it breaks StrBase.jl, so I’m not sure how to proceed. I guess someone has to decide whether this is appropriate for a minor release. Technically, it would have to wait until 2.0. |
If I understood correctly, it seems like it would be fixed relatively easily, no? If so, I think we can move ahead. Triage already decided in favor of the change in (cf. the linked issue), and I will merge later today if no objections. |
Yes, I can make a PR to StrBase.jl. |
@sostock thanks again for this great PR! |
One interesting (apparently untested) fallout that didn't dawn on me until just now: empty OffsetArrays now compare equal where they would have been distinct before; |
Is that good or bad? |
I'm not sure. |
Me neither. This is the API-designer's equivalent of "what's the sound of one hand clapping?" at its finest. And here the 20-something me smugly thought he had avoided squishy things. |
Fixes #29421
This PR makes empty ranges compare equal, i.e.,
1:0 == 2:1
.I only changed the implementation of
==
sinceisequal
does not have specialized methods for ranges and falls back to theAbstractArray
implementation, which already shows the desired behavior. Of course, specializedisequal
methods might still be desirable for better performance. (Should I add them? I’m not sure anyone usesisequal
to compare ranges, so it might not be worth it.)As discussed in #29421, PkgEval should be run to make sure that this does not break any package. Interestingly, it actually broke
Base.split
(also fixed here), because the implementation compared the result of somefindfirst
/findnext
calls to0:-1
(which seems to be a relic from the time before these functions returnednothing
).Should I add a
NEWS.md
entry for this?