View source for 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 [https://timsong-cpp.github.io/lwg-issues/2063 LWG 2063], which replaced it with a conditional noexcept that uses {{tt|is_always_equal}}, which is C++17. Meanwhile, [https://timsong-cpp.github.io/lwg-issues/2016 LWG 2016] tacked on a requirement that POCMA allocators actually meet {{named req|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 {{tt|is_always_equal}} in their {{lc|std::allocator_traits}} regardless of version. Jonathan Wakely wrote that he "[https://gcc.gnu.org/ml/libstdc++/2015-06/msg00096.html 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 [https://timsong-cpp.github.io/lwg-issues/2108 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? [[User:T. Canens|T. Canens]] ([[User talk: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. --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 15:20, 3 April 2017 (PDT)
:: Do we want to say that is_always_equal is also a DR on {{lc|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. [[User:T. Canens|T. Canens]] ([[User talk: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. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 19:39, 5 April 2017 (PDT)

:::Hi,

:::according to Daniel's replies here:

:::&nbsp;&nbsp;<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 <code>noexcept</code>.

:::I think Cppreference should say that the operator is <code>noexcept</code> 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 <code>static_assert</code> on <code>std::is_nothrow_move_assignable< std::string >::value</code> passes on some implementations and not in others, in C++14 mode). <small><span class="autosigned">—&nbsp;Preceding unsigned comment added by [[User:Gennaro Prota|Gennaro Prota]] ([[User talk:Gennaro Prota|talk]] • [[Special:Contributions/Gennaro Prota|contribs]]) </span></small><!-- Template:Unsigned -->

::::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. [[User:T. Canens|T. Canens]] ([[User talk: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. [[User:Gennaro Prota|Gennaro Prota]] ([[User talk:Gennaro Prota|talk]]) 10:31, 1 March 2020 (PST)
::::::See [[Cppreference:FAQ#Why are there differences between the standard and cppreference?|the FAQ]] for our policy on DRs. We are not going to pretend that {{c|std::vector<int>}} is ill-formed in any version of the standard because the {{tt|<int>}} is supposedly parsed as a ''header-name''. (see {{wg21|cwg2000}}). [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 20:00, 2 March 2020 (PST)