[libc++] basic_string::resize_and_overwrite: Adopt LWG3645 (Not voted in yet)

[philnik]

Summary

Adopt LWG3645, which fixes the value categories of basic_string::resize_and_overwrite
https://timsong-cpp.github.io/lwg-issues/3645

[• Quuxplusone]

FWIW, I think this is a good idea (and might motivate LWG to DTRT), but I'm biased. Let's see what @ldionne thinks.
Also, I don't know if @ldionne would want us to mention LWG3645 in some csv file, or say nothing until it's adopted (and of course that question becomes moot if we just defer landing this at all).

libcxx/test/std/strings/basic.string/string.capacity/resize_and_overwrite.pass.cpp

80

You could actually add line 79 to the test today, right? It should work both before and after this patch.

[philnik]

ping @ldionne

[ldionne]

In D116815#3227945, @Quuxplusone wrote:

Also, I don't know if @ldionne would want us to mention LWG3645 in some csv file, or say nothing until it's adopted (and of course that question becomes moot if we just defer landing this at all).

One of the problems with straying from our custom of never shipping something until it's in the Standard is that we don't have a process for doing it. For instance, if we make this change, do we just avoid marking the issue as implemented in the status files because there's no entry for it, and then we mark it as having been implemented since <some LLVM version> once the issue resolution lands in the Standard? That seems somewhat hand-wavy, and if we all died tomorrow (hopefully not), our successors wouldn't have a way to easily tell what happened without digging out this discussion.

This seems like a small enough issue that I wouldn't oppose shipping its resolution even before it's been voted officially, but if we did that, I would like to add an entry in the csv file to track issues we implement that haven't been voted yet.

[And once we have a nice place to put those, I would have a harder time fighting back people who want to ship stuff that's not in the Standard -- but I'm ready for it :-)]

libcxx/include/string

982

WDYT about using _LIBCPP_AUTO_CAST here? It would be closest to the standard.

[ldionne]

In D116815#3244881, @ldionne wrote:

This seems like a small enough issue that I wouldn't oppose shipping its resolution even before it's been voted officially, but if we did that, I would like to add an entry in the csv file to track issues we implement that haven't been voted yet.

To clarify, perhaps I'd suggest adding a new tag to https://libcxx.llvm.org/Status/Cxx2b.html saying something like not-voted-yet, or a new column. Or maybe another table after the LWG issues table. I don't mind the details, but I'd like *some* way of tracking what we're doing here.

[• Quuxplusone]

libcxx/include/string

982

You mean

__erase_to_end(_VSTD::move(__op)(data(), _LIBCPP_AUTO_CAST(__n)));

? I think that's heavier-weight (in terms of #includes and template instantiations) than +__n, but I don't object.
(We could do _LIBCPP_AUTO_CAST(data()) too, but I think we both agree that'd be silly? :)

[philnik]

• Address comments
• Add LWG issue entry

libcxx/docs/Status/Cxx2bIssues.csv

 `3585 <https://wg21.link/LWG3585>`__,"``variant`` converting assignment with immovable alternative","October 2021","",""
 `3589 <https://wg21.link/LWG3589>`__,"The ``const`` lvalue reference overload of ``get`` for ``subrange`` does not constrain ``I`` to be ``copyable`` when ``N == 0``","October 2021","","","|ranges|"
 `3590 <https://wg21.link/LWG3590>`__,"``split_view::base() const &`` is overconstrained","October 2021","","","|ranges|"
 `3591 <https://wg21.link/LWG3591>`__,"``lazy_split_view<input_view>::inner-iterator::base() &&`` invalidates outer iterators","October 2021","","","|ranges|"
 `3592 <https://wg21.link/LWG3592>`__,"``lazy_split_view`` needs to check the simpleness of Pattern","October 2021","","","|ranges|"
 `3593 <https://wg21.link/LWG3593>`__,"Several iterators' ``base() const &`` and ``lazy_split_view::outer-iterator::value_type::end()`` missing ``noexcept``","October 2021","","","|ranges|"
 `3595 <https://wg21.link/LWG3595>`__,"Exposition-only classes proxy and postfix-proxy for ``common_iterator`` should be fully ``constexpr``","October 2021","","","|ranges|"
 "","","","",""
+`3645 <https://wg21.link/LWG3645>`__,"``resize_and_overwrite`` is overspecified to call its callback with lvalues", "Not voted in","|Complete|","14.0",""
+"","","","",""
 No newline at end of file

libcxx/include/string

#endif // _LIBCPP_DEBUG_LEVEL == 2
 
     void reserve(size_type __requested_capacity);
 
 #if _LIBCPP_STD_VER > 20
     template <class _Op>
     _LIBCPP_HIDE_FROM_ABI constexpr
     void resize_and_overwrite(size_type __n, _Op __op) {
       __resize_default_init(__n);
-      pointer __data = data();
-      __erase_to_end(_VSTD::move(__op)(__data, __n));
+      __erase_to_end(_VSTD::move(__op)(data(), _LIBCPP_AUTO_CAST(__n)));
     }
 #endif
 
     _LIBCPP_INLINE_VISIBILITY void __resize_default_init(size_type __n);
 
     _LIBCPP_DEPRECATED_IN_CXX20 _LIBCPP_INLINE_VISIBILITY
     void reserve() _NOEXCEPT {shrink_to_fit();}
     _LIBCPP_INLINE_VISIBILITY

libcxx/test/std/strings/basic.string/string.capacity/resize_and_overwrite.pass.cpp

constexpr bool test() {
   test_truncating<S>(40, 35);
   test_truncating<S>(40, 10);
 
   return true;
 }
 
 void test_value_categories() {
   std::string s;
-  s.resize_and_overwrite(10, [](char*&, size_t&) { return 0; });
+  s.resize_and_overwrite(10, [](char*&&, size_t&&) { return 0; });
+  s.resize_and_overwrite(10, [](char* const&, const size_t&) { return 0; });
   struct RefQualified {
     int operator()(char*, size_t) && { return 0; }
   };
   s.resize_and_overwrite(10, RefQualified{});
 }
 
 int main(int, char**) {
   test<char>();