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.
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.
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:]
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.