Skip to content

[alg.search] search_n. Use consistent wording with search #3261

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.

Sign up for GitHub

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

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
+2 −1
Open

[alg.search] search_n. Use consistent wording with search #3261

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 2 additions & 1 deletion source/algorithms.tex
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -3998,7 +3998,8 @@
such that for every non-negative integer \tcode{n} less than \tcode{count}
the following corresponding conditions hold:
\tcode{*(i + n) == value, pred(*(i + n),value) != false}.
Returns \tcode{last} if no such iterator is found.
Returns \tcode{first} if \tcode{count <= 0},
Copy link
Contributor

@CaseyCarter CaseyCarter Oct 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This normatively duplicates the stated behavior of the first sentence. If we want to clarify the meaning of the first sentence in the count <= 0 case, then this should be a note.

Copy link
Member

@jensmaurer jensmaurer Oct 4, 2019 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And why is this extra provision present for search (without _n)? Given the similar structure, I'd expect the "normative duplication" would apply to both.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I consider it a defect that the redundant provision is present for std::search. Notably none of std::ranges::search, std::search_n, nor std::ranges::search_n have this defect. Spreading the provision from one member of this set to a second does not harmonize the wording of all four.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks. So, we should have an LWG issue to remove the duplication from search and maybe add a note everywhere talking about the "empty range" case. Unless @zygoloid this approach would be editorial.

otherwise returns \tcode{last} if no such iterator is found.

\pnum
\complexity
Expand Down