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

[Zoe Carver via Phabricator via libcxx-commits]

zoecarver 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); }
----------------
WimLeflere wrote:
> 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
Libc++ adds noexcept to some things that aren't required to have it in the standard. But I don't think we add constexpr. Maybe @mclow.lists or @ldionne can confirm this, though. 

> The implementation is based on find(const char*) which is not noexcept (string_view::find).
> So I think it's best to keep it not noexcept.

Well... they're all implemented with `__str_find ` which is unconditionally noexcept so, I think it might make sense. (Given that, it probably also makes sense to mark that `find` function as noexcept, but that's out of scope.) But, we should definitely also make the corresponding `string_view` overload noexpect if we make this one noexecept. 

Separate note: I know the paper suggests using `__self_view::find`, but why not just use `basic_string::find` (which //is// noexecpt, against the standard specification, btw)? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93912