Talk:cpp/numeric/valarray/operator=

Copy assignment operator resize semantics -- misleading for C++03 users

The copy assignment operator (1) only resizes the destination as of C++11. In C++03, if the two operands had different sizes, the behaviour was undefined. (per http://stackoverflow.com/a/31867026/560648) I'm not sure how to format that in this article, but I think it does need indicating. Tomalak geretkal (talk) 15:57, 6 August 2015 (PDT)

Depends on whether LWG 630 (which made the change) counts as a DR that applies retroactively. If not, then the current {{rev inl}} is good. Otherwise, we need something like

The following behavior-changing defect reports were applied retroactively to previously published C++ standards.

DR	Applied to	Behavior as published	Correct behavior
LWG 630	C++03	behavior of operator=(const valarray& other) is undefined if the sizes of the operands are not equal	behavior is well-defined and will resize *this to match the size of other

T. Canens (talk) 18:35, 6 August 2015 (PDT)

I think you are right, it is an accepted defect report against then-current C++03. It wasn't Resolved by some n-numbered paper or punted to LEWG or NAD Future. I think it would be nice to keep the descriptions in DR tables as one-liners where possible, the link is there for full details. --Cubbi (talk) 19:50, 6 August 2015 (PDT)

Where does it say "applied to C++03"? On that page all I can see is "status: C++11". Tomalak geretkal (talk) 03:05, 7 August 2015 (PDT)

Based on discussions in gcc and clang bugzillas and occasionally on stackoverflow, compiler vendors (as represented by Richard Smith, jwakely, etc) treat resolved defect reports (as opposed to accepted proposals in form of N-numbered papers) as applied (retroactively) to the standard that was in force when the resolution was accepted by full committee (sometimes they even jump the gun and implement them ahead of the vote). cppreference started off tagging every behavior-changing DR with the next standard tag, but this differs from apparent practice. Perhaps we can float this on std-discussion or something similarly visible. --Cubbi (talk) 06:29, 7 August 2015 (PDT)

actually, gcc docs for C++03 mode only say "some additional defect reports", while for C++11 and C++14 they say "standard plus amendments". --Cubbi (talk) 06:54, 7 August 2015 (PDT)

,,and posted to std-discussion. --Cubbi (talk) 07:33, 7 August 2015 (PDT)

I think that, regardless of whether LWG technically deems its issue resolutions retroactive, for at least some issues we must write about them as if they were retroactive. For instance,

• We don't want to edit std::weak_ptr::lock() to say that it's not guaranteed to be atomic (and can result in a call to std::terminate()) until C++14 (LWG 2136).
• We don't want to edit std::shared_ptr to say that it is "required" to be implicitly convertible to bool until C++17 (LWG 2411)
• We don't want to edit vector and deque's resize() to say that a resize that shrinks the container guarantees destruction in reverse order since C++14 until C++17 (LWG 2160)

The list goes on and on. The resize() thing is a good example. The specification in the published C++14 standard is clear, easily implementable, and does nothing particularly surprising or unexpected. Yet it makes no sense for us to say that the order of destruction is guaranteed in C++14.

In the more general case, I think we should go with a descriptive approach. If no known implementation differentiates between standard revisions in applying an issue resolution, then we should just document it under the previous revision, with a note similar to {{dr list meow}} but perhaps with a different introductory paragraph (e.g. "The description on this page incorporates the resolutions of the following LWG issues, which may not have been implemented in older C++ implementations."). T. Canens (talk) 19:54, 7 August 2015 (PDT)

based on the response from LWG chair (Alisdair) in std-discussion, LWG doesn't treat DRs as retroactive (although it's been suggested that they do it like CWG). --Cubbi (talk) 22:24, 8 August 2015 (PDT)

I think Alisdair stepped down from the chair. Regardless, whether the issue resolutions are officially retroactive, I think we should document the behavior of existing implementations, and if none of them differentiates between standard revisions, we shouldn't either. T. Canens (talk) 22:30, 8 August 2015 (PDT)