Talk:cpp/string/basic string/operator=

Exception specification on move assignment

This thing is messier than I thought it would be. The unconditional noexcept in C++11 as published is nonsense, as discussed in LWG 2063, which replaced it with a conditional noexcept that uses is_always_equal, which is C++17. Meanwhile, LWG 2016 tacked on a requirement that POCMA allocators actually meet MoveAssignable (shock, I know) and that the move assignment does not throw. The resolution of both issues didn't enter the WP until after C++14's publication. Surveying major implementations:

• libc++ uses POCMA || is_always_equal for C++17 and POCMA && is_nothrow_move_assignable for C++11-14.
• libstdc++ uses POCMA || is_always_equal regardless of standard version.

Both implementations provide is_always_equal in their std::allocator_traits regardless of version. Jonathan Wakely wrote that he "couldn't see a way to add is_always_equal only for C++17 without introducing ODR violations", so he treated it as a DR resolution (for LWG 2108).

So, what do we want to do here? Which portion of these resolutions should go to the DR list and which portion should be considered "new feature" and revboxed? T. Canens (talk) 14:59, 3 April 2017 (PDT)

to add to your survey, VS2015 here uses POCMA || is_always_equal. How about put the C++17 signature in the page, LWG 2063 in a DR list (a rare dr list for an LWG issue), and LWG 2016 in a Notes section. --Cubbi (talk) 15:20, 3 April 2017 (PDT)

Do we want to say that is_always_equal is also a DR on std::allocator_traits? I suppose that isn't too problematic since the big three all provide it unconditionally. Also, if we say that the entire 2063 goes all the way back to C++11, then libc++'s weakening the exception specification in C++<17 modes is problematic. But maybe we can note that separately. T. Canens (talk) 15:30, 3 April 2017 (PDT)

Another possible alternative - though I'm not sure how much I like it - is to drop the noexcept from the C++11 signature entirely, deem the extra noexcept in the implementations in their pre-C++17 mode as (conforming) extensions, and document the conditional noexcept for C++17 only. T. Canens (talk) 19:39, 5 April 2017 (PDT)

Hi,

according to Daniel's replies here:

  <https://lists.isocpp.org/std-discussion/2020/02/0472.php>,

the above doesn't seem correct: LWG 2063 applies to C++17; and, formally, C++11 and C++14 must keep having an unconditional noexcept.

I think Cppreference should say that the operator is noexcept until C++17, with a note saying that implementations may vary on that, because there was a DR on the issue which was only resolved for C++17, but they try to apply a fix anyway (if that's really the reason for their variation---I've seen myself that a static_assert on std::is_nothrow_move_assignable< std::string >::value passes on some implementations and not in others, in C++14 mode). — Preceding unsigned comment added by Gennaro Prota (talk • contribs)

Yes, ISO rules say that DR applies to the immediately previous standard only, and in any event LWG does formal DRs extremely rarely. Nonetheless, we try to be useful, and documenting a known-incorrect thing is not useful. T. Canens (talk) 16:22, 23 February 2020 (PST)

I think we shouldn't lie on this. Let's say what the standard says. Then, a note, referenced to with a "see below" from the function signature, would take care of explaining the situation.

Also, the table of DRs shouldn't say that LWG 2063 applies to C++11.

PS: why doesn't MediaWiki automatically add a signature to comments? At least when the user is logged in. Writing "Preceding unsigned comment added by..." doesn't seem very useful. Gennaro Prota (talk) 10:31, 1 March 2020 (PST)

See the FAQ for our policy on DRs. We are not going to pretend that std::vector<int> is ill-formed in any version of the standard because the <int> is supposedly parsed as a header-name. (see CWG2000). T. Canens (talk) 20:00, 2 March 2020 (PST)