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.