[alg.search] search_n. Use consistent wording with search #3261
Conversation
|
Please squash and force-push your commits. Also, prefix your commit comment with "[alg.search]". That said, there is explicit normative wording for "search" that we get "first1" for an empty second range. This wording is missing from "search_n", although the rest of the description has the same structure. I can't see how this issue would be editorial. |
|
The patch is only for clarification what should be returned from "search_n". I see "first" as a return value is obvious for standard libraries, so, let's document it anyhow to avoid misinterpretation |
|
"obvious for standard libraries": Apparently not, otherwise microsoft/STL#148 wouldn't be tagged "LWG issue needed". |
| @@ -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}, | |||
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
wg21bot
added
the
needs rebase
Hi,
For the
search_nalgorithm the Standard says:It seems that if
n>=0andcount <=0we don't have a chance to apply a predicate. So, we won't find "such iterator". According to this logiclastshould be returned. However, libcxx and Microsoft's C++ Standard Library returnsfirst. According to the issue there was a different interpretation ofsearch_nwording.Moreover,
searchreturnsfirstin the same case. I hope it's just an editorial issue.