[PATCH] D93912: [libc++][P1679] add string contains

[Wim Leflere via Phabricator via llvm-commits]

WimLeflere added inline comments.


================
Comment at: libcxx/include/string:1450
+    constexpr _LIBCPP_INLINE_VISIBILITY
+    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


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D93912/new/

https://reviews.llvm.org/D93912