[libcxx-commits] [PATCH] D93912: [libc++][P1679] add string contains

Wim Leflere via Phabricator via libcxx-commits libcxx-commits at lists.llvm.org
Tue Jan 12 00:17:50 PST 2021

WimLeflere added inline comments.

Comment at: libcxx/include/string:1450
+    bool contains(const value_type* __s) const
+    { return __self_view(data(), size()).contains(__s); }
Quuxplusone wrote:
> zoecarver wrote:
> > Thoughts on making this one noexcept as well? (I know it's not noexcept in the standard, does anyone know the reason for that?)
> [Lakos Rule.](https://quuxplusone.github.io/blog/2018/04/25/the-lakos-rule/) If `__s` is null, or points to a non-null-terminated array, then this overload has UB; whereas the other two overloads never have UB.
> No useful opinion from me on making this one noexcept. Personally I can never remember whether vendors are allowed to add `noexcept`, or `constexpr`, or neither. I also don't know if libc++ thinks it's OK to add either keyword if it's not mandated by the standard, because that might be a portability trap for users (they rely on its being noexcept and then their code breaks when they switch to libstdc++ or something).
The implementation is based on `find(const char*)` which is not `noexcept` ([[ https://github.com/llvm/llvm-project/blob/master/libcxx/include/string_view#L438 | string_view::find ]]).
So I think it's best to keep it not noexcept.

I think a vendor can be more 'strict' than the standard and still be conformant.
In the MS STL they are more strict for example: https://github.com/microsoft/STL/pull/1478#issuecomment-730789583

  rG LLVM Github Monorepo



More information about the libcxx-commits mailing list