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.

### 2058. `valarray` and `begin/end`

Section: 26.7 [numarray] Status: C++14 Submitter: Gabriel Dos Reis Opened: 2011-05-17 Last modified: 2016-01-28

Priority: Not Prioritized

View all other issues in [numarray].

View all issues with C++14 status.

Discussion:

It was just brought to my attention that the pair of functions `begin/end` were added to `valarray` component. Those additions strike me as counter to the long standing agreement that `valarray<T>` is not yet another container. Valarray values are in general supposed to be treated as a whole, and as such has a loose specification allowing expression template techniques.

The addition of these functions sound to me as making it much harder (or close to impossible) to effectively use expression templates as implementation techniques, for no clear benefits.

My recommendation would be to drop `begin/end` - or at least for the `const valarray<T>&` version. I strongly believe those are defects.

[This issue was discussed on the library reflector starting from c++std-lib-30761. Some of the key conclusions of this discussion were:]

1. The `begin/end` members were added to allow `valarray` to participate in the new range-based for-loop by n2930 and not to make them container-like.
2. It is currently underspecified when the iterator values returned from `begin/end` become invalidated. To fix this, these invalidation rules need at least to reflect the invalidation rules of the references returned by the `operator[]` overloads of `valarray` (26.7.2.4 [valarray.access]).
3. A further problem is that the requirements expressed in 26.7.1 [valarray.syn] p.3-5 enforce an implementation to provide further overloads of `begin/end`, if the replacement type technique is used (which was clearly part of the design of `valarray`). Providing such additional overloads would also lead to life-time problems in examples like `begin(x + y)` where `x` and `y` are expressions involving `valarray` objects. To fix this, the `begin/end` overloads could be explicitly excluded from the general statements of 26.7.1 [valarray.syn] p.3-5. This would make it unspecified whether the expression `begin(x + y)` would be well-formed, portable code would need to write this as `begin(std::valarray<T>(x + y))`.

[ 2011 Bloomington ]

The intent of these overloads is entirely to support the new for syntax, and not to create new containers.

Stefanus provides suggested wording.

[2012, Kona]

Moved to Tenatively Ready by post-meeting issues processing group, after confirmation from Gaby.

[2012, Portland: applied to WP]

Proposed resolution:

In 26.7.1 [valarray.syn]/4, make the following insertion:

4 Implementations introducing such replacement types shall provide additional functions and operators as follows:

- for every function taking a `const valarray<T>&` other than `begin` and `end` (26.7.10 [valarray.range]), identical functions taking the replacement types shall be added;
- for every function taking two `const valarray<T>&` arguments, identical functions taking every combination of `const valarray<T>&` and replacement types shall be added.

In 26.7.10 [valarray.range], make the following insertion:

1 In the `begin` and `end` function templates that follow, unspecified1 is a type that meets the requirements of a mutable random access iterator (24.2.7) whose `value_type` is the template parameter `T` and whose `reference` type is `T&`. unspecified2 is a type that meets the requirements of a constant random access iterator (24.2.7) whose `value_type` is the template parameter `T` and whose `reference` type is `const T&`.

2 The iterators returned by `begin` and `end` for an array are guaranteed to be valid until the member function `resize(size_t, T)` (26.7.2.8 [valarray.members]) is called for that array or until the lifetime of that array ends, whichever happens first.