[libcxx-commits] [PATCH] D113013: [libc++] Implement P1072R10 (std::basic_string::resize_and_overwrite)

[Nikolas Klauser via Phabricator via libcxx-commits]

philnik added inline comments.


================
Comment at: libcxx/include/string:994
+    template <class _Operation>
+    _LIBCPP_HIDE_FROM_ABI constexpr void resize_and_overwrite(size_type __n, _Operation __op)
+        requires requires(_Operation __o) { {__o(pointer{}, size_type{})} -> _VSTD::convertible_to<size_type>; } {
----------------
Quuxplusone wrote:
> Line-break after `constexpr`, please.
> Also, I certainly wouldn't complain if `s/_Operation/_Op/`.
What do you mean by 

> Also, I certainly wouldn't complain if s/_Operation/_Op/.

?


================
Comment at: libcxx/include/string:995
+    _LIBCPP_HIDE_FROM_ABI constexpr void resize_and_overwrite(size_type __n, _Operation __op)
+        requires requires(_Operation __o) { {__o(pointer{}, size_type{})} -> _VSTD::convertible_to<size_type>; } {
+      if (__n > capacity())
----------------
Quuxplusone wrote:
> http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p1072r10.html doesn't mention any //Constraints//, only a //Mandates// that `std::move(__o)(declval<_CharT*&>(), __n)` should have an integer-like type. I don't think "integer-like-ness" is expressible in C++, but prove me wrong. :)
> Anyway, this function definitely should not be constrained, because (1) the standard says it shouldn't be, and (2) if we get our constraint wrong then we're needlessly preventing valid use-cases.
> 
> ...Hm, I guess [p1072r10] has a minor wording bug, because obviously they intended to mandate the type of `std::move(op)(std::move(p), std::move(n))`, not `std::move(op)(p, n)`. I think we should "do what they mean, not what they say."
I think the paper is right. What would be the point of moving a raw pointer or a size_type?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113013