Skip to content

Fix _customContainsEquatableElement implementation for Stride* types #39903

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

Merged
merged 2 commits into from
Oct 25, 2021

Conversation

xwu
Copy link
Collaborator

@xwu xwu commented Oct 25, 2021

Recently reported on the Swift forums, Stride* types fail to account for the scenario of striding "backwards" in its implementations of _customContainsEquatableElement when determining if an element is contained within the given interval.

This PR fixes that issue. Specifically, we modify the implementation to branch on the sign of _stride. Recall that we deliberately allow striding in the "opposite" direction of that specified by from and to/through, which results in an empty sequence—in that case, this PR results in _customContainsEquatableElement correctly returning false regardless of element without special cases.

Resolves SR-15384.

@xwu
Copy link
Collaborator Author

xwu commented Oct 25, 2021

@swift-ci test

@stephentyrone
Copy link
Contributor

stephentyrone commented Oct 25, 2021

I'm slightly confused as to why these functions only return either false or nil. It appears that this makes us always fall back on the predicate version of contains when the element is present; did we just punt on doing a real implementation of these?

@xwu
Copy link
Collaborator Author

xwu commented Oct 25, 2021

I didn’t invent these custom overloads, but my understanding is that they’re meant to provide a fast path when an element is clearly contained or not contained in the sequence.

As you know of course, in the general case, computing whether striding lands on any particular value between start and end is significantly more involved. I’m just committing a correctness fix here. Whether there are other scenarios that could benefit (performance-wise) from being quickly ruled in or out within this function as opposed to falling back can be left for future exploration.

@xwu xwu requested a review from airspeedswift October 25, 2021 16:37
@stephentyrone
Copy link
Contributor

Yeah, I'm not asking you to solve the general case, I'm just surprised that it was implemented this way (and that there's no explanation or TODO to be found). I would appreciate if you added a note to that effect.

@stephentyrone stephentyrone self-requested a review October 25, 2021 17:57
@xwu xwu merged commit fa4d08a into swiftlang:main Oct 25, 2021
@xwu xwu deleted the stride-custom-contains-fix branch October 25, 2021 18:07
@xwu
Copy link
Collaborator Author

xwu commented Oct 25, 2021

Yeah, I'm not asking you to solve the general case, I'm just surprised that it was implemented this way (and that there's no explanation or TODO to be found). I would appreciate if you added a note to that effect.

Sure thing—since the tests have mercifully completed successfully I'll follow up in a subsequent PR.

@xwu
Copy link
Collaborator Author

xwu commented Oct 25, 2021

@stephentyrone Worth nominating for 5.5?

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

Successfully merging this pull request may close these issues.

2 participants