Proposed resolution:

In [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 ([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 [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) ([valarray.members]) is called for that array or until the lifetime of that array ends, whichever happens first.

[ 2012, Portland: applied to WP ]

[ 2012, Kona ]

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

[ 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.

[ 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 ([valarray.access]).
3. A further problem is that the requirements expressed in [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 [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)).

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.