Date: Sat, 3 Oct 2020 11:46:47 -0400
On Sat, Oct 3, 2020 at 9:06 AM Kosher Yosher via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
> @Jason I think you mixed something up there. std::count_until means `Count the elements until the given predicate returns true`, which is correct. And we already have the same semantics in std::is_sorted_until btw:
> https://en.cppreference.com/w/cpp/algorithm/is_sorted_until
It's not the same semantics. Not in the sense I'm talking about.
`count` counts the items in the range for which the given value is
equal to the item in the range. `count_if` counts the items for which
the predicate tested against that item is true. `count_until` counts
the first X items for which the predicate tests false.
One of these things is not like the other. The treatment of the
predicate is *backwards* in `count_until`. By contrast,
`is_sorted_until` treats the comparison functor the same way as the
equivalent `is_sorted` call.
`is_sorted_until` is a variation of `is_sorted`. `count_until` is not
a variation of `count`.
> Lastly, legacy codebases are stuck with index-based APIs and internals. If you own the codebase then you can refactor that to iterators. But you are going to have a hard time convincing everyone to change this out of nowhere in a large, commercial environment. What you can do is start encouraging people to use this template as a bridge instead of writing new for loops and occasionally refactoring existing function bodies with it. Over time, you will squash the amount of code to refactor to get iterators in place, and the final switch will be much closer to replacing the count_until instances with find_if, it gets you halfway there, great! That's a much easier sales pitch than "I want to replace all indices with iterators now because it's better on paper". These codebases are real and extending a branch to bridge this gap to modern C++ is not a bad thing. I think we all know how difficult this can be and having something in your toolkit to do that is a welcome addition to me.
And they can do the exact same thing with the `enumerate` view
version. We already have the tool in our toolbelt, so why do we need a
very slightly shorter version of it?
<std-proposals_at_[hidden]> wrote:
>
> @Jason I think you mixed something up there. std::count_until means `Count the elements until the given predicate returns true`, which is correct. And we already have the same semantics in std::is_sorted_until btw:
> https://en.cppreference.com/w/cpp/algorithm/is_sorted_until
It's not the same semantics. Not in the sense I'm talking about.
`count` counts the items in the range for which the given value is
equal to the item in the range. `count_if` counts the items for which
the predicate tested against that item is true. `count_until` counts
the first X items for which the predicate tests false.
One of these things is not like the other. The treatment of the
predicate is *backwards* in `count_until`. By contrast,
`is_sorted_until` treats the comparison functor the same way as the
equivalent `is_sorted` call.
`is_sorted_until` is a variation of `is_sorted`. `count_until` is not
a variation of `count`.
> Lastly, legacy codebases are stuck with index-based APIs and internals. If you own the codebase then you can refactor that to iterators. But you are going to have a hard time convincing everyone to change this out of nowhere in a large, commercial environment. What you can do is start encouraging people to use this template as a bridge instead of writing new for loops and occasionally refactoring existing function bodies with it. Over time, you will squash the amount of code to refactor to get iterators in place, and the final switch will be much closer to replacing the count_until instances with find_if, it gets you halfway there, great! That's a much easier sales pitch than "I want to replace all indices with iterators now because it's better on paper". These codebases are real and extending a branch to bridge this gap to modern C++ is not a bad thing. I think we all know how difficult this can be and having something in your toolkit to do that is a welcome addition to me.
And they can do the exact same thing with the `enumerate` view
version. We already have the tool in our toolbelt, so why do we need a
very slightly shorter version of it?
Received on 2020-10-03 10:47:01