This page is a snapshot from the LWG issues list, see the Library Active Issues List for more information and the meaning of C++14 status.

### 2071. `std::valarray` move-assignment

Section: 28.6.2.3 [valarray.assign] Status: C++14 Submitter: Paolo Carlini Opened: 2011-05-05 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [valarray.assign].

View all issues with C++14 status.

Discussion:

Yesterday I noticed that the language we have in the FDIS about `std::valarray` move assignment is inconsistent with the resolution of LWG 675. Indeed, we guarantee constant complexity (vs linear complexity). We also want it to be noexcept, that is more subtle, but again it's at variance with all the containers.

Also, even if we suppose that LWG 675 applies only to the containers proper, I don't think the current "as if by calling resize(v.size())" is internally consistent with the noexcept requirement.

So, what do we really want for `std::valarray`? Shall we maybe just strike or fix the as-if, consider it some sort of pasto from the copy-assignment text, thus keep the noexcept and constant complexity requirements (essentially the whole operation would boild down to a swap of POD data members). Or LWG 675 should be explicitly extended to `std::valarray` too? In that case both noexcept and constant complexity would go, I think, and the operation would boil down to the moral equivalent of `clear()` (which doesn't really exist in this case) + `swap`?

Howard: I agree the current wording is incorrect. The complexity should be linear in `size()` (not `v.size()`) because the first thing this operator needs to do is `resize(0)` (or `clear()` as you put it).

I think we can keep the `noexcept`.

As for proper wording, here's a first suggestion:

> Effects: `*this` obtains the value of `v`. The value of `v` after the assignment is not specified.

> Complexity: linear.

See also reflector discussion starting with c++std-lib-30690.

[2012, Kona]

Move to Ready.

Some discussion on the types supported by `valarray` concludes that the wording is trying to say something similar to the core wording for trivial types, but significantly predates it, and does allow for types with non-trivial destructors. Howard notes that the only reason for linear complexity, rather than constant, is to support types with non-trivial destructors.

AJM suggests replacing the word 'value' with 'state', but straw poll prefers moving forward with the current wording, 5 to 2.

[2012, Portland: applied to WP]

Proposed resolution:

This wording is relative to the FDIS.

In 28.6.2.3 [valarray.assign] update as follows:

>     valarray<T>& operator=(valarray<T>&& v) noexcept;

> > 3 Effects: `*this` obtains the value of `v`. If the length of `v` is not equal to the length of `*this`, resizes `*this` to make the two arrays the same length, as if by calling `resize(v.size())`, before performing the assignment.The value of `v` after the assignment is not specified.

> > 4 Complexity: Constant Linear.