Subject: Re: [std-proposals] Finding the index of an element (std::find_first_index)
From: Jason McKesson (jmckesson_at_[hidden])
Date: 2020-10-04 13:43:42
On Sat, Oct 3, 2020 at 3:29 PM Kosher Yosher via Std-Proposals
> > 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
STD-PROPOSALS list run by email@example.com
Standard Proposals Archives on Google Groups