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?