[libcxx-commits] [PATCH] D124079: [libc++] Implement ranges::find_end, ranges::search{, _n}
Konstantin Varlamov via Phabricator via libcxx-commits
libcxx-commits at lists.llvm.org
Wed Jul 6 14:55:57 PDT 2022
var-const accepted this revision as: var-const.
var-const added a comment.
LGTM with one remaining question.
================
Comment at: libcxx/include/__algorithm/ranges_search.h:68
+ if (__size2 <= 0)
+ return {__first1, __first1};
+ if constexpr (sized_range<_Range1>) {
----------------
philnik wrote:
> var-const wrote:
> > Hmm, I'd like to double-check this. IIUC, the relevant section is
> >
> > > `{i, i + (last2 - first2)}`, where `i` is the first iterator in the range `[first1, last1 - (last2 - first2))` such that for every non-negative integer `n` less than `last2 - first2` the condition
> > `bool(invoke(pred, invoke(proj1, *(i + n)), invoke(proj2, *(first2 + n))))` is `true`.
> >
> > However, if `last2 - first2` is zero, there exists no non-negative integer `n` less than that. It seems like it would mean that no such iterator `i` can exist and thus the algorithm should go to the next clause and return `{last1, last1}`.
> Yes, the non-negative integers less than zero is the empty set. Normally "all of an empty set" is trivially true.
Hmm, I might be missing something (I wrote the original comment a while ago), but it seems that if `last2 - first2 == 0`, the current implementation would return `{first1, first1}`, whereas it should return `{last1, last1}` (assuming I'm correct that the "if no such iterator exists" cause applies). `first1` isn't necessarily equal to `last1` in this case, so returning `{first1, first1}` isn't equivalent to returning `{last1, last1}`, even if both are empty sets.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D124079/new/
https://reviews.llvm.org/D124079
More information about the libcxx-commits
mailing list