I think we have gone over the same talking points long enough to conclude
that we are not going to come to an agreement here. Therefore, I would like
to end the discussion now and drop the proposal. Thanks!

On Sun, 4 Oct 2020 at 19:44, Jason McKesson via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> On Sat, Oct 3, 2020 at 3:29 PM Kosher Yosher via Std-Proposals
> <std-proposals_at_[hidden]> wrote:
> >
> > > One of these things is not like the other. The treatment of the
> predicate is *backwards* in `count_until`.
> > Why is that a problem? If I had accidentally named it "count_while" then
> that'd be a mistake to correct but it says "_until". They are two different
> functions that count elements.
>
> To understand why this is a problem, we need to unpack the thread of
> discussion.
>
> Arthur suggested "count_until" with this statement:
>
> > So I guess maybe the classic-STL name for what you want is `count_until`.
>
> You agreed with this reasoning:
>
> > like Arthur pointed out, fits in with the already existing count_X
> functions sort of, it's not an alien family of functions.
>
> So right there, that's the question: is the name `count_until` "alien"
> to the standard library?
>
> I argued that it is alien, and my reason for this is that the suffix
> "until" does not work like similar algorithm suffixes.
>
> The behavior of `count_if` relative to `count` is solely about h .
> `count` is just a special-case of `count_if` and could be implemented
> in terms of it. `count_until` is not and cannot be implemented in
> terms of either `count` or `count_if`. `count_until` treats its
> predicate in a completely different way from `count_if`.
>
> Similarly `is_sorted` is just a special case of `is_sorted_until`, and
> the former can be implemented in terms of the latter. Again, this is
> not the case of `count_until` relative to `count`.
>
> The name "count_until" *suggests* that the "until" suffix is being
> used like `is_sorted_until`. But it's not. With `is_sorted_until`, you
> have a variation of the `is_sorted` algorithm, one which subsumes the
> shorter named one. That isn't the case here. `count_until` is as
> different an algorithm from `count` as `lower_bound` is from `find`.
>
> So it seems clear to me that the name is "alien" to some degree with
> the standard algorithm library's nomenclature.
>
> It seems obvious to me that the correct name is "find_index". That's
> what you asked for, after all: do exactly what `find` does, just
> return an index instead of an iterator. You can implement `find` in
> terms of `find_index` (though you *really* shouldn't), so it fits into
> the suffix nomenclature of algorithm naming.
>
> And if we genuinely believe that helping C programmers use algorithms
> by discouraging use of iterators in favor of their preferred indices
> is a legitimate thing to do (though I honestly cannot fathom how that
> works), then the standard ought to reserve the "_index" suffix for
> functions that offer this behavior. After all, if an index-based
> `find` is a legitimate thing to have, why not other index-based
> algorithms too?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>