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: 29.6 [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.
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:]
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.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 (29.6.2.4 [valarray.access]).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 29.6.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 29.6.1 [valarray.syn]/4, make the following insertion:
4 Implementations introducing such replacement types shall provide additional functions and operators as follows:
const valarray<T>& other than begin and end (29.6.10 [valarray.range]), identical functions taking the replacement types shall be added;const valarray<T>& arguments, identical functions taking every combination of const valarray<T>& and replacement types shall be added.In 29.6.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) (29.6.2.8 [valarray.members]) is called for that array or until the lifetime of that array ends, whichever happens first.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4