On Sun, 2 Jun 2019 at 18:28, Pedro Alves <pedro_at_[hidden]> wrote:
>
> On 5/31/19 1:31 PM, Ville Voutilainen via Std-Proposals wrote:
> > On Fri, 31 May 2019 at 15:06, Barry Revzin via Std-Proposals
> > <std-proposals_at_[hidden]> wrote:
> >>> If we take one step backward, even if it is a useful pattern, we may turn to regex for more readability and extendibility rather than “find != npos”.
> >>> The name has already been used in other facilities like “set” or “map” with completely different semantics, which may confuse the beginners and decrease “teachability”.
> >> How do map::contains() and set::contains() have "completely different semantics" than the proposed string::contains()? They seem exactly the same to me. It's even the same motivation - wanting to avoid the boilerplate of map.find(x) != map.end() is the same as wanting to avoid the boilerplate of str.find(x) != npos.
> >
> > Well, {map,set}::contains is a logarithmic operation, string::contains
> > would be linear. That could well be an argument for naming the linear
> > operation differently from the logarithmic one.
> >
>
> Why is that an argument for "contains", when "find" has the exact
> same difference, and is named the same in all those containers?

Mostly because find() was never a log-or-better function, whereas
contains() is. I do think that's a fairly weak argument,
and a rather hypothetical conjecture at that; personally I think we
should just add contains() to everything that has a find() (and maybe
to even more things)
and be done with this.