<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Issue 2058: valarray and begin&#47;end</title>
<meta property="og:title" content="Issue 2058: valarray and begin&#47;end">
<meta property="og:description" content="C++ library issue. Status: C++14">
<meta property="og:url" content="https://cplusplus.github.io/LWG/issue2058.html">
<meta property="og:type" content="website">
<meta property="og:image" content="http://cplusplus.github.io/LWG/images/cpp_logo.png">
<meta property="og:image:alt" content="C++ logo">
<style>
  p {text-align:justify}
  li {text-align:justify}
  pre code.backtick::before { content: "`" }
  pre code.backtick::after { content: "`" }
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table.issues-index { border: 1px solid; border-collapse: collapse; }
  table.issues-index th { text-align: center; padding: 4px; border: 1px solid; }
  table.issues-index td { padding: 4px; border: 1px solid; }
  table.issues-index td:nth-child(1) { text-align: right; }
  table.issues-index td:nth-child(2) { text-align: left; }
  table.issues-index td:nth-child(3) { text-align: left; }
  table.issues-index td:nth-child(4) { text-align: left; }
  table.issues-index td:nth-child(5) { text-align: center; }
  table.issues-index td:nth-child(6) { text-align: center; }
  table.issues-index td:nth-child(7) { text-align: left; }
  table.issues-index td:nth-child(5) span.no-pr { color: red; }
  @media (prefers-color-scheme: dark) {
     html {
        color: #ddd;
        background-color: black;
     }
     ins {
        background-color: #225522
     }
     del {
        background-color: #662222
     }
     a {
        color: #6af
     }
     a:visited {
        color: #6af
     }
     blockquote.note
     {
        background-color: rgba(255, 255, 255, .10)
     }
  }
</style>
</head>
<body>
<hr>
<p><em>This page is a snapshot from the LWG issues list, see the <a href="lwg-active.html">Library Active Issues List</a> for more information and the meaning of <a href="lwg-active.html#C++14">C++14</a> status.</em></p>
<h3 id="2058"><a href="lwg-defects.html#2058">2058</a>. <code>valarray</code> and <code>begin&#47;end</code></h3>
<p><b>Section:</b> 29.6 <a href="https://wg21.link/numarray">[numarray]</a> <b>Status:</b> <a href="lwg-active.html#C++14">C++14</a>
 <b>Submitter:</b> Gabriel Dos Reis <b>Opened:</b> 2011-05-17 <b>Last modified:</b> 2016-01-28</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#numarray">issues</a> in [numarray].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#C++14">C++14</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It was just brought to my attention that the pair of functions
<code>begin&#47;end</code> were added to <code>valarray</code> component.
Those additions strike me as counter to the long standing agreement
that <code>valarray&lt;T&gt;</code> 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.
<p/>
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.
<p/>
My recommendation would be to drop <code>begin&#47;end</code> - or at least for the
<code>const valarray&lt;T&gt;&amp;</code> version. I strongly believe those 
are defects.
</p>
<p><i>[This issue was discussed on the library reflector starting from c++std-lib-30761.
Some of the key conclusions of this discussion were:]</i></p>

<ol>
<li>The <code>begin&#47;end</code> members were added to allow <code>valarray</code> to participate
in the new range-based for-loop by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2930.html">n2930</a>
and not to make them container-like.</li>
<li>It is currently underspecified when the iterator values returned from
<code>begin&#47;end</code> become invalidated. To fix this, these invalidation rules need at
least to reflect the invalidation rules of the references returned by the
<code>operator[]</code> overloads of <code>valarray</code> (29.6.2.4 <a href="https://wg21.link/valarray.access">[valarray.access]</a>).
</li>
<li>A further problem is that the requirements expressed in 29.6.1 <a href="https://wg21.link/valarray.syn">[valarray.syn]</a> p.3-5
enforce an implementation to provide further overloads of <code>begin&#47;end</code>, if the
replacement type technique is used (which was clearly part of the design of <code>valarray</code>).
Providing such additional overloads would also lead to life-time problems in examples like 
<code>begin(x + y)</code> where <code>x</code> and <code>y</code> are expressions involving <code>valarray</code> 
objects. To fix this, the <code>begin&#47;end</code> overloads could be explicitly excluded from the 
general statements of 29.6.1 <a href="https://wg21.link/valarray.syn">[valarray.syn]</a> p.3-5. This would make it unspecified
whether the expression <code>begin(x + y)</code> would be well-formed, portable code would
need to write this as <code>begin(std::valarray&lt;T&gt;(x + y))</code>.</li>
</ol>

<p><i>[
2011 Bloomington
]</i></p>


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

<p>
Stefanus provides suggested wording.
</p>


<p><i>[2012, Kona]</i></p>

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

<p><i>[2012, Portland: applied to WP]</i></p>




<p id="res-2058"><b>Proposed resolution:</b></p>
<p>
In 29.6.1 <a href="https://wg21.link/valarray.syn">[valarray.syn]</a>&#47;4, make the following <ins>insertion</ins>:
</p>

<p>
4 Implementations introducing such replacement types shall provide additional functions and operators as
follows:
</p>
<ul>
<li>for every function taking a <code>const valarray&lt;T&gt;&amp;</code> <ins>other than <code>begin</code> and <code>end</code>
(29.6.10 <a href="https://wg21.link/valarray.range">[valarray.range]</a>)</ins>, identical functions taking the replacement types shall be added;
</li>
<li>
for every function taking two <code>const valarray&lt;T&gt;&amp;</code> arguments, identical functions taking every combination
of <code>const valarray&lt;T&gt;&amp;</code> and replacement types shall be added.
</li>
</ul>

<p>
In 29.6.10 <a href="https://wg21.link/valarray.range">[valarray.range]</a>, make the following <ins>insertion</ins>:
</p>
<p> 
1 In the <code>begin</code> and <code>end</code> function templates that follow, <i>unspecified</i>1 is a type that meets
the requirements of a mutable random access iterator (24.2.7) whose <code>value_type</code> is the template parameter
<code>T</code> and whose <code>reference</code> type is <code>T&amp;</code>. <i>unspecified</i>2 is a type that meets the
requirements of a constant random access iterator (24.2.7) whose <code>value_type</code> is the template parameter
<code>T</code> and whose <code>reference</code> type is <code>const T&amp;</code>.
</p>
<p><ins>
2 The iterators  returned by <code>begin</code> and <code>end</code> for an array are guaranteed to be valid until the
member function <code>resize(size_t, T)</code> (29.6.2.8 <a href="https://wg21.link/valarray.members">[valarray.members]</a>) is called for that array or until
the lifetime of that array ends, whichever happens first.
</ins></p>





</body>
</html>
