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?