<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Kona</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  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 {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Kona</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P1457R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2019-01-21 at 04:35:38 UTC</p>
</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Marshall Clow &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2>Ready Issues</h2>
<hr>
<h3><a name="3012" href="#3012">3012</a><sup><a href="https://cplusplus.github.io/LWG/issue3012">(i)</a></sup>. <tt>atomic&lt;T&gt;</tt> is unimplementable for non-<tt>is_trivially_copy_constructible T</tt></h3>
<p><b>Section:</b> 30.7 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2017-08-16 <b>Last modified:</b> 2018-11-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
30.7 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> requires that <tt>T</tt> for <tt>std::atomic</tt> is trivially copyable. 
Unfortunately, that's not sufficient to implement <tt>atomic</tt>. Consider <tt>atomic&lt;T&gt;::load</tt>, which 
wants to look something like this:
</p>
<blockquote><pre>
template&lt;class T&gt;
struct atomic {
  __compiler_magic_storage_for_t storage;

  T load(memory_order = memory_order_seq_cst) const {
    return __magic_intrinsic(storage);
  }

};
</pre></blockquote>
<p>
Forming this return statement, though, requires that <tt>T</tt> is copy constructible &mdash; trivially copyable things 
aren't necessarily copyable! For example, the following is trivially copyable but breaks libc++, libstdc++, and msvc++:
</p>
<blockquote><pre>
struct NonAssignable {
  int i;
  NonAssignable() = delete;
  NonAssignable(int) : i(0) {}
  NonAssignable(const NonAssignable&amp;) = delete;
  NonAssignable(NonAssignable&amp;&amp;) = default;
  NonAssignable&amp; operator=(const NonAssignable&amp;) = delete;
  NonAssignable&amp; operator=(NonAssignable&amp;&amp;) = delete;
  ~NonAssignable() = default;
};
</pre></blockquote>
<p>
All three standard libraries are happy as long as <tt>T</tt> is trivially copy constructible, assignability is not required. 
Casey Carter says that we might want to still require trivially copy assignable though, since what happens when you do an 
<tt>atomic&lt;T&gt;::store</tt> is morally an "assignment" even if it doesn't use the user's assignment operator.
</p>

<p><i>[2017-11 Albuquerque Wednesday issue processing]</i></p>

<p>Status to Open; Casey and STL to work with Billy for better wording.</p>
<p>Should this include trivially copyable as well as trivially copy assignable?</p>

<p>2017-11-09, Billy O'Neal provides updated wording.</p>
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This resolution is relative to <a href="http://wg21.link/n4687">N4687</a>.</p>

<ol>
<li><p>Edit 30.7 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> as indicated:</p>

<blockquote>
<p>
-1- <ins>If <tt>is_trivially_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed</ins><del>The
template argument for <tt>T</tt> shall be trivially copyable (6.7 <a href="https://wg21.link/basic.types">[basic.types]</a>)</del>. [<i>Note:</i> Type
arguments that are not also statically initializable may be difficult to use. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This resolution is relative to <a href="http://wg21.link/n4687">N4687</a>.</p>

<ol>
<li><p>Edit 30.7 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> as indicated:</p>

<blockquote>
<p>
-1- <ins>If <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt> or if
<tt>is_trivially_copyable_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed</ins><del>The
template argument for <tt>T</tt> shall be trivially copyable (6.7 <a href="https://wg21.link/basic.types">[basic.types]</a>)</del>. [<i>Note:</i> Type
arguments that are not also statically initializable may be difficult to use. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2017-11-12, Tomasz comments and suggests alternative wording]</i></p>

<p>
According to my understanding during Albuquerque Saturday issue processing we agreed that we want the type used 
with the atomics to have non-deleted and trivial copy/move construction and assignment.
<p/>
Wording note: <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt> include semantic requirements that are not 
checkable at compile time, so these are requirements imposed on the user and cannot be validated by an
implementation without heroic efforts.
</p>

<p><i>[2018-11 San Diego Thursday night issue processing]</i></p>

<p>Status to Ready.</p>


<p><b>Proposed resolution:</b></p>
<p>This resolution is relative to <a href="http://wg21.link/n4700">N4700</a>.</p>

<ol>
<li><p>Edit 30.7 <a href="https://wg21.link/atomics.types.generic">[atomics.types.generic]</a> as indicated:</p>

<blockquote>
<p>
-1- The template argument for <tt>T</tt> shall <ins>meet the <tt>CopyConstructible</tt> and <tt>CopyAssignable</tt>
requirements. If <tt>is_trivially_copyable_v&lt;T&gt; &amp;&amp; is_copy_constructible_v&lt;T&gt; &amp;&amp; 
is_move_constructible_v&lt;T&gt; &amp;&amp; is_copy_assignable_v&lt;T&gt; &amp;&amp; is_move_assignable_v&lt;T&gt;</tt> 
is <tt>false</tt>, the program is ill-formed</ins><del>be trivially copyable (6.7 <a href="https://wg21.link/basic.types">[basic.types]</a>)</del>. 
[<i>Note:</i> Type arguments that are not also statically initializable may be difficult to use. &mdash; <i>end note</i>]
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3040" href="#3040">3040</a><sup><a href="https://cplusplus.github.io/LWG/issue3040">(i)</a></sup>. <tt>basic_string_view::starts_with</tt> <i>Effects</i> are incorrect</h3>
<p><b>Section:</b> 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2017-11-29 <b>Last modified:</b> 2018-11-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#string.view.ops">issues</a> in [string.view.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The effects of <tt>starts_with</tt> are described as equivalent to <tt>return compare(0, npos, x) == 0</tt>.
<p/>
This is incorrect, because it returns <tt>false</tt> when you check to see if any sequence begins with the empty sequence. 
(There are other failure cases, but that one's easy)
<p/>
As a drive-by fix, we can make the <i>Effects:</i> for <tt>starts_with</tt> and <tt>ends_with</tt> clearer.
<p/>
Those are the second and proposed third changes, and they are not required.
</p>

<p><i>[
2017-12-13 Moved to Tentatively Ready after 8 positive votes for P0 on c++std-lib.
]</i></p>


<strong>Previous resolution: [SUPERSEDED]</strong>

<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4713">N4713</a>.</p>

<ol>
<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p20 as indicated:</p>

<blockquote>
<pre>constexpr bool starts_with(basic_string_view x) const noexcept;</pre>
<blockquote>
<p>
-20- <i>Effects:</i> Equivalent to: <tt>return <ins>size() &gt;= x.size() &amp;&amp;</ins> 
compare(0, <del>npos</del><ins>x.size()</ins>, x) == 0;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p21 as indicated:</p>
<blockquote>
<pre>constexpr bool starts_with(charT x) const noexcept;</pre>
<blockquote>
<p>
-21- <i>Effects:</i> Equivalent to: <tt>return <ins>!empty() &amp;&amp; 
traits::eq(front(), x)</ins><del>starts_with(basic_string_view(&amp;x, 1))</del>;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p24 as indicated:</p>

<blockquote>
<pre>constexpr bool ends_with(charT x) const noexcept;</pre>
<blockquote>
<p>
-24- <i>Effects:</i> Equivalent to: <tt>return <ins>!empty() &amp;&amp; traits::eq(back(), 
x)</ins><del>ends_with(basic_string_view(&amp;x, 1))</del>;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-01-23, Reopening due to a comment of Billy Robert O'Neal III requesting a change of the proposed 
wording]</i></p>

<p>
The currently suggested wording has:
</p>
<blockquote><p>
<i>Effects:</i> Equivalent to: <tt>return size() &gt;= x.size() &amp;&amp; compare(0, x.size(), x) == 0;</tt>
</p></blockquote>
<p>
but <tt>compare()</tt> already does the <tt>size() &gt;= x.size()</tt> check.
<p/>
It seems like it should say:
</p>
<blockquote><p>
<i>Effects:</i> Equivalent to: <tt>return substr(0, x.size()) == x;</tt>
</p></blockquote>

<p><i>[
2018-10-29 Moved to Tentatively Ready after 5 positive votes for P0 on c++std-lib.
]</i></p>




<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4713">N4713</a>.</p>

<ol>
<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p20 as indicated:</p>

<blockquote>
<pre>constexpr bool starts_with(basic_string_view x) const noexcept;</pre>
<blockquote>
<p>
-20- <i>Effects:</i> Equivalent to: <tt>return <ins>substr(0, x.size()) == x</ins><del>compare(0, 
npos, x) == 0</del>;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p21 as indicated:</p>
<blockquote>
<pre>constexpr bool starts_with(charT x) const noexcept;</pre>
<blockquote>
<p>
-21- <i>Effects:</i> Equivalent to: <tt>return <ins>!empty() &amp;&amp; 
traits::eq(front(), x)</ins><del>starts_with(basic_string_view(&amp;x, 1))</del>;</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.4.2.6 <a href="https://wg21.link/string.view.ops">[string.view.ops]</a> p24 as indicated:</p>

<blockquote>
<pre>constexpr bool ends_with(charT x) const noexcept;</pre>
<blockquote>
<p>
-24- <i>Effects:</i> Equivalent to: <tt>return <ins>!empty() &amp;&amp; traits::eq(back(), 
x)</ins><del>ends_with(basic_string_view(&amp;x, 1))</del>;</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3077" href="#3077">3077</a><sup><a href="https://cplusplus.github.io/LWG/issue3077">(i)</a></sup>. <tt>(push|emplace)_back</tt> should invalidate the <tt>end</tt> iterator</h3>
<p><b>Section:</b> 21.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-03-10 <b>Last modified:</b> 2018-12-03</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.modifiers">issues</a> in [vector.modifiers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
21.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a> paragraph 1 specifies that <tt>emplace_back</tt>
and <tt>push_back</tt> do not invalidate iterators before the insertion point when
reallocation is unnecessary:
<blockquote>
<i>Remarks:</i> Causes reallocation if the new size is greater than the old capacity.
Reallocation invalidates all the references, pointers, and iterators referring to
the elements in the sequence. If no reallocation happens, all the iterators and
references before the insertion point remain valid. [&hellip;]
</blockquote>
This statement is redundant, given the blanket wording in
21.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> paragraph 12:
<blockquote>
Unless otherwise specified (either explicitly or by defining a function in terms
of other functions), invoking a container member function or passing a container
as an argument to a library function shall not invalidate iterators to, or change
the values of, objects within that container.
</blockquote>
It seems that this second sentence (1) should be a note that reminds us that the
blanket wording applies here when no reallocation occurs, and/or (2) actually
intends to specify that iterators at and after the insertion point are invalidated.
</p>
<p>
Also, it seems intended that reallocation should invalidate the <tt>end</tt>
iterator as well.
</p>

<p><i>[2018-06-18 after reflector discussion]</i></p>

<p>Priority set to 3</p>
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li>
<p>Edit 21.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a> as indicated:</p>
<blockquote>
<p>
-1- <i>Remarks:</i> <ins>Invalidates the past-the-end iterator.</ins> Causes
reallocation if the new size is greater than the old capacity. Reallocation
invalidates all the references, pointers, and iterators referring to the elements
in the sequence. <ins>[<i>Note:</i></ins> If no reallocation happens, all the
iterators and references before the insertion point remain
valid.<ins>&mdash;<i>end note</i>]</ins> If an exception is thrown [&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-11-28 Casey provides an updated P/R]</i></p>

Per discussion in the prioritization thread on the reflector.

<p><i>[2018-12-01 Status to Tentatively Ready after seven positive votes on the reflector.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to the post-San Diego working draft.
</p>

<ol>
<li>
<p>Change 20.3.2.4 <a href="https://wg21.link/string.capacity">[string.capacity]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
</blockquote>
<p>
-11- <i>Effects:</i> <tt>shrink_­to_­fit</tt> is a non-binding request to reduce
<tt>capacity()</tt> to <tt>size()</tt>. [ <i>Note:</i> The request is
non-binding to allow latitude for implementation-specific optimizations.
&mdash; <i>end note</i> ] It does not increase <tt>capacity()</tt>, but may
reduce <tt>capacity()</tt> by causing reallocation.
</p><p>
-12- <i>Complexity:</i> <ins>If the size is not equal to the old capacity,</ins>
linear in the size of the sequence<ins>; otherwise constant</ins>.
</p><p>
-13- <i>Remarks:</i> Reallocation invalidates all the references, pointers, and
iterators referring to the elements in the sequence<ins>,</ins> as well as the
past-the-end iterator. <ins>[ <i>Note:</i></ins> If no reallocation happens,
they remain valid. <ins>&mdash; <i>end note</i> ]</ins>
</p>
</blockquote>
</li>
<li>
<p>Change 21.3.8.3 <a href="https://wg21.link/deque.capacity">[deque.capacity]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
</blockquote>
<p>
-5- <i>Requires:</i> <tt>T</tt> shall be <i><tt>Cpp17MoveInsertable</tt></i>
into <tt>*this</tt>.
</p><p>
-6- <i>Effects:</i> <tt>shrink_­to_­fit</tt> is a non-binding request to reduce
memory use but does not change the size of the sequence. [ <i>Note:</i> The
request is non-binding to allow latitude for implementation-specific
optimizations. &mdash;<i>end note</i> ] If <ins>the size is equal to
the old capacity, or if</ins> an exception is thrown other than by
the move constructor of a non-<i><tt>Cpp17CopyInsertable</tt></i>
<tt>T</tt><ins>, then</ins> there are no effects.
</p><p>
-7- <i>Complexity:</i> <ins>If the size is not equal to the old capacity,</ins>
linear in the size of the sequence<ins>; otherwise constant</ins>.
</p><p>
-8- <i>Remarks:</i> <del><tt>shrink_to_fit</tt></del> <ins>If the size is not
equal to the old capacity, then</ins> invalidates all the references, pointers,
and iterators referring to the elements in the sequence<ins>,</ins> as well as
the past-the-end iterator.
</p>
</blockquote>
</li>
<li>
<p>Change 21.3.11.3 <a href="https://wg21.link/vector.capacity">[vector.capacity]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
void reserve(size_type n);
</pre>
</blockquote>
<p>[&hellip;]</p>
<p>
-7- <i>Remarks:</i> Reallocation invalidates all the references, pointers, and
iterators referring to the elements in the sequence<ins>, as well as the
past-the-end iterator</ins>. <ins>[ <i>Note:</i> If no reallocation happens,
they remain valid. &mdash; <i>end note</i> ]</ins> No reallocation shall take place
during insertions that happen after a call to <tt>reserve()</tt> until <del>the
time when</del> an insertion would make the size of the vector greater than the
value of <tt>capacity()</tt>.
</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
</blockquote>
<p>[&hellip;]</p>
<p>
-10- <i>Complexity:</i> <ins>If reallocation happens,</ins> linear in the size
of the sequence.
</p><p>
-11- <i>Remarks:</i> Reallocation invalidates all the references, pointers, and
iterators referring to the elements in the sequence<ins>,</ins> as well as the
past-the-end iterator. <ins>[ <i>Note:</i></ins> If no reallocation happens,
they remain valid. <ins>&mdash; <i>end
note</i> ]</ins>
</p>
</blockquote>
</li>
<li>
<p>Change 21.3.11.5 <a href="https://wg21.link/vector.modifiers">[vector.modifiers]</a> as indicated:</p>
<blockquote>
<p>
-1- <i>Remarks:</i> Causes reallocation if the new size is greater than the old
capacity. Reallocation invalidates all the references, pointers, and iterators
referring to the elements in the sequence <ins>as well as the past-the-end
iterator</ins>. If no reallocation happens, <del>all the iterators and
references</del> <ins>then references, pointers, and iterators</ins> before the
insertion point remain valid <ins>but those at or after the insertion point,
including the past-the-end iterator, are invalidated</ins>.
If an exception is thrown [&hellip;]
</p><p>
-2- <i>Complexity:</i> <del>The complexity is</del> <ins>If reallocation
happens, linear in the number of elements of the resulting vector;
otherwise</ins> linear in the number of elements inserted plus the distance to
the end of the vector.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3087" href="#3087">3087</a><sup><a href="https://cplusplus.github.io/LWG/issue3087">(i)</a></sup>. One final <tt>&amp;x</tt> in &sect;[list.ops]</h3>
<p><b>Section:</b> 21.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2018-03-19 <b>Last modified:</b> 2018-11-11</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#list.ops">active issues</a> in [list.ops].</p>
<p><b>View all other</b> <a href="lwg-index.html#list.ops">issues</a> in [list.ops].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#3017">3017</a> missed an instance of <tt>&amp;x</tt> in 21.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> p14.
</p>

<p><i>[2018-06-18 after reflector discussion]</i></p>

<p>Priority set to 3</p>

<p><i>[2018-10-15 Status to Tentatively Ready after seven positive votes on the reflector.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4727">N4727</a>.</p>

<ol>
<li><p>Edit 21.3.10.5 <a href="https://wg21.link/list.ops">[list.ops]</a> as indicated:</p>
<blockquote>
<pre>
void splice(const_iterator position, list&amp; x, const_iterator first,
            const_iterator last);
void splice(const_iterator position, list&amp;&amp; x, const_iterator first,
            const_iterator last);
</pre>
<blockquote>
<p>
-11- <i>Requires:</i> [&hellip;]
<p/>
-12- <i>Effects:</i> [&hellip;]
<p/>
-13- <i>Throws:</i> Nothing.
<p/>
-14- <i>Complexity:</i> Constant time if <tt><del>&amp;</del><ins>addressof(</ins>x<ins>)</ins> == this</tt>; otherwise, linear time.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3101" href="#3101">3101</a><sup><a href="https://cplusplus.github.io/LWG/issue3101">(i)</a></sup>. <tt>span</tt>'s <tt>Container</tt> constructors need another constraint</h3>
<p><b>Section:</b> 21.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2018-04-12 <b>Last modified:</b> 2018-11-11</p>
<p><b>Priority: </b>1
</p>
<p><b>View all other</b> <a href="lwg-index.html#span.cons">issues</a> in [span.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When I overhauled <tt>span</tt>'s constructor constraints, I was careful about the built-in array, <tt>std::array</tt>, 
and converting <tt>span</tt> constructors. These types contain bounds information, so we can achieve safety at 
compile-time by permitting implicit conversions if and only if the destination extent is dynamic (this accepts 
anything by recording the size at runtime) or the source and destination extents are identical. However, I missed 
the fact that the <tt>Container</tt> constructors are the opposite case. A <tt>Container</tt> (e.g. a <tt>vector</tt>) 
has a size that's known only at runtime. It's safe to convert this to a <tt>span</tt> with <tt>dynamic_extent</tt>, 
but for consistency and safety, this shouldn't implicitly convert to a <tt>span</tt> with fixed extent. (The more 
verbose <tt>(ptr, count)</tt> and <tt>(first, last)</tt> constructors are available to construct fixed extent spans 
from runtime-length ranges. Note that debug precondition checks are equally possible with the <tt>Container</tt> and 
<tt>(ptr, count)</tt>/<tt>(first, last)</tt> constructors. The issue is that implicit conversions are notoriously 
problematic, so they should be permitted only when they are absolutely known to be safe.)
</p>

<p><i>[2018-04-24 Priority set to 1 after discussion on the reflector.]</i></p>


<p><i>[2018-06 Rapperswil Thursday issues processing]</i></p>

<p>Status to LEWG. Should this be ill-formed, or fail at runtime if the container is too small?
Discussion on the reflector <a href="http://lists.isocpp.org/lib/2018/04/6719.php">here</a>.</p>

<p><i>[2018-11 San Diego Saturday]</i></p>

<p>LEWG said that they're fine with the proposed resolution. Status to Tentatively Ready.</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4741">N4741</a>.</p>

<blockquote>
<ol>
<li>
<p>Edit 21.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class Container&gt; constexpr span(Container&amp; cont);
template&lt;class Container&gt; constexpr span(const Container&amp; cont);
</pre>
<blockquote>
<p>
-14- <i>Requires:</i> <tt>[data(cont), data(cont) + size(cont))</tt> shall be a valid range. <del>If <tt>extent</tt> is 
not equal to <tt>dynamic_extent</tt>, then <tt>size(cont)</tt> shall be equal to <tt>extent</tt>.</del>
<p/>
-15- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the range <tt>[data(cont), data(cont) + size(cont))</tt>.
<p/>
-16- <i>Postconditions:</i> <tt>size() == size(cont) &amp;&amp; data() == data(cont)</tt>.
<p/>
-17- <i>Throws:</i> What and when <tt>data(cont)</tt> and <tt>size(cont)</tt> throw.
<p/>
-18- <i>Remarks:</i> These constructors shall not participate in overload resolution unless:
</p>
<ol style="list-style-type: none">
<li><p><ins>(18.?) &mdash; <tt>extent == dynamic_extent</tt>,</ins></p></li>
<li><p>(18.1) &mdash; <tt>Container</tt> is not a specialization of <tt>span</tt>,</p></li>
<li><p>(18.2) &mdash; <tt>Container</tt> is not a specialization of <tt>array</tt>,</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>





<hr>
<h3><a name="3112" href="#3112">3112</a><sup><a href="https://cplusplus.github.io/LWG/issue3112">(i)</a></sup>. <tt>system_error</tt> and <tt>filesystem_error</tt> constructors taking a <tt>string</tt> may not be able 
to meet their postconditions</h3>
<p><b>Section:</b> 18.5.7.2 <a href="https://wg21.link/syserr.syserr.members">[syserr.syserr.members]</a>, 28.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2018-05-10 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#syserr.syserr.members">active issues</a> in [syserr.syserr.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#syserr.syserr.members">issues</a> in [syserr.syserr.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructors of <tt>system_error</tt> and <tt>filesystem_error</tt> taking a <tt>std::string</tt> <tt>what_arg</tt> 
are specified to have a postcondition of <tt>string(what()).find(what_arg) != string::npos</tt> (or the equivalent with 
<tt>string_view</tt>). This is not possible if <tt>what_arg</tt> contains an embedded null character.
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 0 and status to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4727">N4727</a>.</p>

<blockquote class="note"> 
<p>
<i>Drafting note:</i> This contains a drive-by editorial change to use <tt>string_view</tt> for these postconditions rather 
than <tt>string</tt>.
</p>
</blockquote>

<ol>
<li><p>Edit 18.5.7.2 <a href="https://wg21.link/syserr.syserr.members">[syserr.syserr.members]</a> p1-4 as indicated:</p>
<blockquote>
<pre>
system_error(error_code ec, const string&amp; what_arg);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
<p/>
-2- <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>string<ins>_view</ins>(what()).find(what_arg<ins>.c_str()</ins>) 
!= string<ins>_view</ins>::npos</tt>.
</p>
</blockquote>
<pre>
system_error(error_code ec, const char* what_arg);
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
<p/>
-4- <i>Postconditions:</i> <tt>code() == ec</tt> and <tt>string<ins>_view</ins>(what()).find(what_arg) 
!= string<ins>_view</ins>::npos</tt>.
</p>
</blockquote>
</blockquote>
</li>
<li><p>Edit 18.5.7.2 <a href="https://wg21.link/syserr.syserr.members">[syserr.syserr.members]</a> p7-10 as indicated:</p>
<blockquote>
<pre>
system_error(int ev, const error_category&amp; ecat, const std::string&amp; what_arg);
</pre>
<blockquote>
<p>
-7- <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
<p/>
-8- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>string<ins>_view</ins>(what()).find(what_arg<ins>.c_str()</ins>) 
!= string<ins>_view</ins>::npos</tt>.
</p>
</blockquote>
<pre>
system_error(int ev, const error_category&amp; ecat, const char* what_arg);
</pre>
<blockquote>
<p>
-9- <i>Effects:</i> Constructs an object of class <tt>system_error</tt>.
<p/>
-10- <i>Postconditions:</i> <tt>code() == error_code(ev, ecat)</tt> and <tt>string<ins>_view</ins>(what()).find(what_arg) 
!= string<ins>_view</ins>::npos</tt>.
</p>
</blockquote>
</blockquote>
</li>
<li><p>Edit 28.11.8.1 <a href="https://wg21.link/fs.filesystem_error.members">[fs.filesystem_error.members]</a> p2-4 as indicated:</p>
<blockquote>
<pre>
filesystem_error(const string&amp; what_arg, error_code ec);
</pre>
<blockquote>
<p>
-2- <i>Postconditions:</i>
</p>
<ul>
<li> <tt>code() == ec</tt>, </li>
<li> <tt>path1().empty() == true</tt>,</li>
<li> <tt>path2().empty() == true</tt>, and</li>
<li> <tt>string_view(what()).find(what_arg<ins>.c_str()</ins>) != string_view::npos</tt>.</li>
</ul>
</blockquote>
<pre>
filesystem_error(const string&amp; what_arg, const path&amp; p1, error_code ec);
</pre>
<blockquote>
<p>
-3- <i>Postconditions:</i>
</p>
<ul>
<li> <tt>code() == ec</tt>, </li>
<li> <tt>path1()</tt> returns a reference to the stored copy of <tt>p1</tt>,</li>
<li> <tt>path2().empty() == true</tt>, and</li>
<li> <tt>string_view(what()).find(what_arg<ins>.c_str()</ins>) != string_view::npos</tt>.</li>
</ul>
</blockquote>
<pre>
filesystem_error(const string&amp; what_arg, const path&amp; p1, const path&amp; p2, error_code ec);
</pre>
<blockquote>
<p>
-4- <i>Postconditions:</i>
</p>
<ul>
<li> <tt>code() == ec</tt>, </li>
<li> <tt>path1()</tt> returns a reference to the stored copy of <tt>p1</tt>,</li>
<li> <tt>path2()</tt> returns a reference to the stored copy of <tt>p2</tt>,</li>
<li> <tt>string_view(what()).find(what_arg<ins>.c_str()</ins>) != string_view::npos</tt>.</li>
</ul>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3119" href="#3119">3119</a><sup><a href="https://cplusplus.github.io/LWG/issue3119">(i)</a></sup>. Program-definedness of closure types</h3>
<p><b>Section:</b> 99 [defns.program.defined.spec] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2018-06-09 <b>Last modified:</b> 2018-11-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The description of closure types in 7.5.5.1 <a href="https://wg21.link/expr.prim.lambda.closure">[expr.prim.lambda.closure]</a> says:
</p>
<blockquote>
<p>
An implementation may define the closure type differently [&hellip;]
</p>
</blockquote>
<p>
The proposed resolution to LWG <a href="lwg-defects.html#2139">2139</a> defines a "program-defined type" to be a
</p>
<blockquote>
<p>
class type or enumeration type that is not part of the C++ standard library and not defined by the implementation,
or an instantiation of a program-defined specialization
</p>
</blockquote>
<p>
I am not sure that the intent of whether closure types are or are not program-defined types is clearly
conveyed by the wording.
</p>

<p><i>[2018-06-23 after reflector discussion]</i></p>

<p>Priority set to 2</p>

<p><i>[2018-08-14 Casey provides additional discussion and a Proposed Resolution]</i></p>

<p>
We use the term "program-defined" in the library specification to ensure that
two users cannot create conflicts in a component in namespace <tt>std</tt> by
specifying different behaviors for the same type. For example, we allow users to
specialize <tt>common_type</tt> when at least one of the parameters is a
program-defined type. Since two users cannot define the same program-defined
type, this rule prevents two users (or libraries) defining the same
specialization of <tt>std::common_type</tt>.
</p><p>
Since it's guaranteed that even distinct utterances of identical lambda
expressions produce closures with distinct types
(7.5.5.1 <a href="https://wg21.link/expr.prim.lambda.closure">[expr.prim.lambda.closure]</a>), adding closure types to our term
"program-defined type" is consistent with the intended use despite that such
types are technically defined by the implementation.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="https://wg21.link/n4762">N4762</a>.</p>

<ul>
<li><p>Modify 15.3.20 <a href="https://wg21.link/defns.prog.def.type">[defns.prog.def.type]</a> as follows:</p>
<blockquote>
<b>program-defined type</b><br/>
class type or enumeration type that is not part of the C++ standard library and
not defined by the implementation <ins>(except for closure types
(7.5.5.1 <a href="https://wg21.link/expr.prim.lambda.closure">[expr.prim.lambda.closure]</a>) for program-defined lambda
expressions)</ins>, or an instantiation of a program-defined specialization
</blockquote>
</li>
</ul>
</blockquote>

<p><i>[2018-08-23 Batavia Issues processing]</i></p>

<p>Updated wording</p>

<p><i>[2018-11 San Diego Thursday night issue processing]</i></p>

<p>Status to Ready.</p>


<p><b>Proposed resolution:</b></p>

<p>This wording is relative to <a href="https://wg21.link/n4762">N4762</a>.</p>

<ul>
<li><p>Modify 15.3.20 <a href="https://wg21.link/defns.prog.def.type">[defns.prog.def.type]</a> as follows:</p>
<blockquote>
<b>program-defined type</b><br/>
<ins>non-closure </ins>class type or enumeration type that is not part of the 
C++ standard library and not defined by the implementation, 
<ins>or a closure type of a non-implementation-provided lambda expression, </ins>
or an instantiation of a program-defined specialization
</blockquote>
</li>
</ul>






<hr>
<h3><a name="3133" href="#3133">3133</a><sup><a href="https://cplusplus.github.io/LWG/issue3133">(i)</a></sup>. Modernizing numeric type requirements</h3>
<p><b>Section:</b> 25.2 <a href="https://wg21.link/numeric.requirements">[numeric.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2018-07-05 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#numeric.requirements">issues</a> in [numeric.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.2 <a href="https://wg21.link/numeric.requirements">[numeric.requirements]</a> contains some very old wording that hasn't been changed since C++98
except for issue <a href="lwg-defects.html#2699">2699</a>. As a result, it is at once over- and under-restrictive. For example:
</p>
<ul>
  <li>It requires a class to have various member functions, but not that said member functions be actually
      callable (non-ambiguous, non-deleted) or called by the applicable operations;</li>
  <li>It doesn't disallow function or array types;</li>
  <li>It disallows <i>ref-qualifier</i>s on the assignment operator by restricting the signature;</li>
  <li>It bans unary <tt>operator&amp;</tt> for class types, but not enumeration types; and</li>
  <li>It tries to impose semantic equivalence requirements on <tt>T</tt>'s special member functions, but
      doesn't require that copying produces an equivalent value to the original.</li>
</ul>
<p>
We can significantly clean up this wording by using the existing named requirements. For ease of review,
the following table provides a side-by-side comparison of the current and proposed wording.
</p>
<table border="1">
<tr style="text-align:center">
  <th>Before</th>
  <th>After</th>
</tr>
<tr>
  <td>A C++ program shall instantiate these components only with a type <tt>T</tt>
      that satisfies the following requirements: [<i>Footnote</i> &hellip; ]</td>
  <td>A C++ program shall instantiate these components only with a <ins>cv-unqualified object</ins> type <tt>T</tt>
      that satisfies the <ins><i>Cpp17DefaultConstructible</i>, <i>Cpp17CopyConstructible</i>, <i>Cpp17CopyAssignable</i>,
      and <i>Cpp17Destructible</i></ins><del>following</del> requirements<ins> (15.5.3.1 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a>).</ins><del>:</del></td>
</tr>
<tr>
  <td>(1.1) &mdash; <tt>T</tt> is not an abstract class (it has no pure virtual member functions);</td>
  <td><i>Cpp17DefaultConstructible</i></td>
</tr>
<tr>
  <td>(1.2) &mdash; <tt>T</tt> is not a reference type; <br/>
      (1.3) &mdash; <tt>T</tt> is not cv-qualified; </td>
  <td>Implied by "cv-unqualified object type"</td>
</tr>
<tr>
  <td>(1.4) &mdash; If <tt>T</tt> is a class, it has a public default constructor;</td>
  <td><i>Cpp17DefaultConstructible</i></td>
</tr>
<tr>
  <td>(1.5) &mdash; If <tt>T</tt> is a class, it has a public copy constructor 
      with the signature <tt>T::T(const T&amp;)</tt>;</td>
  <td><i>Cpp17CopyConstructible</i></td>
</tr>
<tr>
  <td>(1.6) &mdash; If <tt>T</tt> is a class, it has a public destructor;</td>
  <td><i>Cpp17Destructible</i></td>
</tr>
<tr>
  <td>(1.7) &mdash; If <tt>T</tt> is a class, it has a public copy assignment operator whose signature is either
      <tt>T&amp; T::operator=(const T&amp;)</tt> or <tt>T&amp; T::operator=(T);</tt></td>
  <td><i>Cpp17CopyAssignable</i></td>
</tr>
<tr>
  <td>(1.8) &mdash; If <tt>T</tt> is a class,  its assignment operator, copy and default constructors, and destructor
      shall correspond to each other in the following sense:<br/>
      (1.8.1) &mdash; Initialization of raw storage using the copy constructor on the value of <tt>T()</tt>, however 
      obtained, is semantically equivalent to value-initialization of the same raw storage.<br/>
      (1.8.2) &mdash; Initialization of raw storage using the default constructor, followed by assignment, is 
      semantically equivalent to initialization of raw storage using the copy constructor.<br/>
      (1.8.3) &mdash; Destruction of an object, followed by initialization of its raw storage using the copy constructor,
      is semantically equivalent to assignment to the original object.<br/>
      [<i>Note:</i> [&hellip;] &mdash; <i>end note</i>]
  </td>
  <td>These requirements are implied by <i>Cpp17CopyConstructible</i> and <i>Cpp17CopyAssignable</i>'s requirement that 
      the value of the copy is equivalent to the source.
  </td>
</tr>
<tr>
  <td>(1.9) &mdash; If <tt>T</tt> is a class, it does not overload unary <tt>operator&amp;</tt>.</td>
  <td><i>omitted now that we have <tt>std::addressof</tt></i></td>
</tr>
</table>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 0 and status to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to the post-Rapperswil 2018 working draft.
</p>

<ol>
<li>
<p>
Edit 25.2 <a href="https://wg21.link/numeric.requirements">[numeric.requirements]</a> p1 as indicated, striking the entire bulleted list:
</p>
<blockquote>
<p>
-1- The <tt>complex</tt> and <tt>valarray</tt> components are parameterized by the type of information they contain and manipulate.
A C++ program shall instantiate these components only with a <ins>cv-unqualified object</ins> type <tt>T</tt>
that satisfies the <ins><i>Cpp17DefaultConstructible</i>, <i>Cpp17CopyConstructible</i>, <i>Cpp17CopyAssignable</i>,
and <i>Cpp17Destructible</i></ins><del>following</del> requirements<ins> (15.5.3.1 <a href="https://wg21.link/utility.arg.requirements">[utility.arg.requirements]</a>).</ins>
<del>:</del>[<i>Footnote:</i> &hellip; ]
</p>
<blockquote>
<p><del>(1.1) &mdash; <tt>T</tt> is not an abstract class (it has no pure virtual member functions);</del>
<p/>
<del>[&hellip;]</del>
<p/>
<del>(1.9) &mdash; If <tt>T</tt> is a class, it does not overload unary <tt>operator&amp;</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>
<li>
<p>
Edit 25.7.2.4 <a href="https://wg21.link/valarray.access">[valarray.access]</a> p3-4 as indicated:
</p>
<blockquote>
<pre>
const T&amp;  operator[](size_t n) const;
T&amp; operator[](size_t n);
</pre>
<blockquote>
<p> 
-1- <i>Requires:</i> <tt>n &lt; size()</tt>.
<p/>
-2- <i>Returns:</i> [&hellip;]
<p/>
-3- <i>Remarks</i>: The expression <tt><del>&amp;</del><ins>addressof(</ins>a[i+j]<ins>)</ins> ==
    <del>&amp;</del><ins>addressof(</ins>a[i]<ins>)</ins> + j</tt> evaluates to <tt>true</tt> for all <tt>size_t i</tt>
    and <tt>size_t j</tt> such that <tt>i+j &lt; a.size()</tt>.
<p/>
-4- The expression <tt><del>&amp;</del><ins>addressof(</ins>a[i]<ins>)</ins> !=
    <del>&amp;</del><ins>addressof(</ins>b[j]<ins>)</ins></tt> evaluates to <tt>true</tt> for any two arrays <tt>a</tt> 
    and <tt>b</tt> and for any <tt>size_t i</tt> and <tt>size_t j</tt> such that <tt>i &lt; a.size()</tt> and <tt>j &lt; b.size()</tt>.
    [<i>Note:</i> [&hellip;] &mdash; <i>end note</i> ]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3144" href="#3144">3144</a><sup><a href="https://cplusplus.github.io/LWG/issue3144">(i)</a></sup>. <tt>span</tt> does not have a <tt>const_pointer</tt> typedef</h3>
<p><b>Section:</b> 21.7.3.1 <a href="https://wg21.link/span.overview">[span.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Louis Dionne <b>Opened:</b> 2018-07-23 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#span.overview">issues</a> in [span.overview].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::span</tt> does not have a typedef for <tt>const_pointer</tt> and <tt>const_reference</tt>. According to 
Marshall Clow, this is merely an oversight.
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 0 and status to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://wg21.link/n4750">N4750</a>.
</p>

<ol>
<li>
<p>Change 21.7.3.1 <a href="https://wg21.link/span.overview">[span.overview]</a>, class template <tt>span</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class ElementType, ptrdiff_t Extent = dynamic_extent&gt;
  class span {
  public:
    <i>// constants and types</i>
    using element_type = ElementType;
    using value_type = remove_cv_t&lt;ElementType&gt;;
    using index_type = ptrdiff_t;
    using difference_type = ptrdiff_t;
    using pointer = element_type*;
    <ins>using const_pointer = const element_type*;</ins>
    using reference = element_type&amp;;
    <ins>using const_reference = const element_type&amp;;</ins>
    using iterator = <i>implementation-defined</i>;
    using const_iterator = <i>implementation-defined</i>;
    using reverse_iterator = reverse_iterator&lt;iterator&gt;;
    using const_reverse_iterator = reverse_iterator&lt;const_iterator&gt;;
    static constexpr index_type extent = Extent;
  
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3173" href="#3173">3173</a><sup><a href="https://cplusplus.github.io/LWG/issue3173">(i)</a></sup>. Enable CTAD for <i><tt>ref-view</tt></i></h3>
<p><b>Section:</b> 23.8.3.1 <a href="https://wg21.link/range.view.ref">[range.view.ref]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-12-09 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In the specification of <tt>view::all</tt> in 23.8.3 <a href="https://wg21.link/range.all">[range.all]</a>,
<a href="https://wg21.link/range.all#2.2">paragraph 2.2</a> states that
<tt>view::all(E)</tt> is sometimes expression-equivalent to
"<tt><i>ref-view</i>{E}</tt> if that expression is well-formed". Unfortunately,
the expression <tt><i>ref-view</i>{E}</tt> is <strong>never</strong> well-formed:
<tt><i>ref-view</i></tt>'s only non-default constructor is a
perfect-forwarding-ish constructor template that accepts only arguments that
convert to lvalues of the <tt><i>ref-view</i></tt>'s template argument type, and
either do not convert to rvalues or have a better lvalue conversion (similar to
the <tt>reference_wrapper</tt> converting constructor
(19.14.5.1 <a href="https://wg21.link/refwrap.const">[refwrap.const]</a>) after issue <a href="lwg-defects.html#2993">2993</a>).
</p><p>
Presumably this breakage was not intentional, and we should add a deduction
guide to enable class template argument deduction to function as intended by
<a href="https://wg21.link/range.all#2.2">paragraph 2.2</a>.
</p>

<p><i>[2018-12-16 Status to Tentatively Ready after six positive votes on the reflector.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4791">N4791</a>.</p>

<ol>
<li><p>Modify the <tt><i>ref-view</i></tt> class synopsis
in  [ranges.view.ref] as follows:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;Range R&gt;
    requires is_object_v&lt;R&gt;
  class <i>ref-view</i> : public view_interface&lt;<i>ref-view</i>&lt;R&gt;&gt; {
    [&hellip;]
  };

  <ins>template&lt;class R&gt;</ins>
    <ins><i>ref_view</i>(R&amp;) -> <i>ref_view</i>&lt;R&gt;;</ins>
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3179" href="#3179">3179</a><sup><a href="https://cplusplus.github.io/LWG/issue3179">(i)</a></sup>. <tt>subrange</tt> should always model <tt>Range</tt></h3>
<p><b>Section:</b> 23.6.3.1 <a href="https://wg21.link/range.subrange.ctor">[range.subrange.ctor]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-12-21 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constructors of <tt>subrange</tt> place no requirements on the iterator and
sentinel values from which a <tt>subrange</tt> is constructed. They allow
constructions like <tt>subrange{myvec.end(), myvec.begin()}</tt> in which the
resulting <tt>subrange</tt> isn't in the domain of the <tt>Range</tt> concept
which requires that "<tt>[ranges::begin(r), ranges::end(r))</tt> denotes a
range" (<a href="https://wg21.link/range.range#3.1">[range.range]/3.1</a>).
We should forbid the construction of abominable values like this to enforce the
useful semantic that values of <tt>subrange</tt> are always in the domain of
<tt>Range</tt>.
</p><p>
(From <a href="https://github.com/ericniebler/stl2/issues/597">ericniebler/stl2#597</a>.)
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 0 and status to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4791">N4791</a>.</p>

<ol>
<li><p>Change 23.6.3.1 <a href="https://wg21.link/range.subrange.ctor">[range.subrange.ctor]</a> as indicated:</p>
<blockquote>
<blockquote>
<pre>
constexpr subrange(I i, S s) requires (!StoreSize);
</pre>
</blockquote>
<p>
<ins>-?- <i>Expects:</i> <tt>[i, s)</tt> is a valid range.</ins>
</p><p>
-1- <i>Effects:</i> Initializes <tt>begin_</tt> with <tt>i</tt> and
<tt>end_</tt> with <tt>s</tt>.
</p>
<blockquote>
<pre>
constexpr subrange(I i, S s, iter_difference_t&lt;I&gt; n)
  requires (K == subrange_kind::sized);
</pre>
</blockquote>
<p>
-2- <i>Expects:</i> <ins><tt>[i, s)</tt> is a valid range, and</ins>
<tt>n == ranges::distance(i, s)</tt>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3180" href="#3180">3180</a><sup><a href="https://cplusplus.github.io/LWG/issue3180">(i)</a></sup>. Inconsistently named return type for <tt>ranges::minmax_element</tt></h3>
<p><b>Section:</b> 24.4 <a href="https://wg21.link/algorithm.syn">[algorithm.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-12-21 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The overloads of <tt>std::ranges::minmax_element</tt> are specified to return
<tt>std::ranges::minmax_result</tt>, which is inconsistent with the intended
design. When an algorithm <tt>foo</tt> returns an aggregate of multiple results,
the return type should be named <tt>foo_result</tt>.
The spec should introduce an alias <tt>minmax_element_result</tt> for
<tt>minmax_result</tt> and use that alias as the return type of the
<tt>std::ranges::minmax_element</tt> overloads.
</p>

<p><i>[2019-01-11 Status to Tentatively Ready after five positive votes on the reflector.]</i></p>

<p>
During that reflector discussion several contributers questioned the choice of alias templates to denote
algorithm result types or particular apsects of it. Since this approach had been approved by LEWG before, 
it was suggested to those opponents to instead write a paper, because changing this as part of this issue 
would be a design change that would require a more global fixing approach.
</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4791">N4791</a>.</p>

<ol>
<li><p>Change 24.4 <a href="https://wg21.link/algorithm.syn">[algorithm.syn]</a> as indicated, and adjust the
declarations of <tt>std::ranges::minmax_element</tt>
in 24.7.8 <a href="https://wg21.link/alg.min.max">[alg.min.max]</a> to agree:</p>
<blockquote>
<pre>
[&hellip;]
template&lt;class ExecutionPolicy, class ForwardIterator, class Compare&gt;
  pair&lt;ForwardIterator, ForwardIterator&gt;
    minmax_element(ExecutionPolicy&amp;&amp; exec, // see 24.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a>
                   ForwardIterator first, ForwardIterator last, Compare comp);

namespace ranges {
  <ins>template&lt;class I&gt;</ins>
  <ins>using minmax_element_result = minmax_result&lt;I&gt;;</ins>

  template&lt;ForwardIterator I, Sentinel&lt;I&gt; S, class Proj = identity,
           IndirectStrictWeakOrder&lt;projected&lt;I, Proj&gt;&gt; Comp = ranges::less&lt;&gt;&gt;
    constexpr minmax_<ins>element_</ins>result&lt;I&gt;
      minmax_element(I first, S last, Comp comp = {}, Proj proj = {});
  template&lt;ForwardRange R, class Proj = identity,
           IndirectStrictWeakOrder&lt;projected&lt;iterator_t&lt;R&gt;, Proj&gt;&gt; Comp = ranges::less&lt;&gt;&gt;
    constexpr minmax_<ins>element_</ins>result&lt;safe_iterator_t&lt;R&gt;&gt;
      minmax_element(R&amp;&amp; r, Comp comp = {}, Proj proj = {});
}

// 24.7.9 <a href="https://wg21.link/alg.clamp">[alg.clamp]</a>, bounded value
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3182" href="#3182">3182</a><sup><a href="https://cplusplus.github.io/LWG/issue3182">(i)</a></sup>. Specification of <tt>Same</tt> could be clearer</h3>
<p><b>Section:</b> 17.4.2 <a href="https://wg21.link/concept.same">[concept.same]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-01-05 <b>Last modified:</b> 2019-01-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of the <tt>Same</tt> concept in 17.4.2 <a href="https://wg21.link/concept.same">[concept.same]</a>:
</p>
<blockquote>
<pre>
template&lt;class T, class U&gt;
  concept Same = is_same_v&lt;T, U&gt;;
</pre>
<p>
-1- <tt>Same&lt;T, U&gt;</tt> subsumes <tt>Same&lt;U, T&gt;</tt> and vice versa.
</p>
</blockquote>
<p>
seems contradictory. From the concept definition alone, it is <em>not</em> the
case that <tt>Same&lt;T, U&gt;</tt> subsumes <tt>Same&lt;U, T&gt;</tt> nor vice
versa. Paragraph 1 is trying to tell us that there's some magic that provides
the stated subsumption relationship, but to a casual reader it appears to be a
mis-annotated note. We should either add a note to explain what's actually
happening here, or define the concept in such a way that it naturally
provides the specified subsumption relationship.
</p><p>
Given that there's a straightforward library implementation of the symmetric
subsumption idiom, the latter option seems preferable.
</p>

<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to and status to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4791">N4791</a>.</p>

<ol>
<li><p>Change 17.4.2 <a href="https://wg21.link/concept.same">[concept.same]</a> as follows:</p>
<blockquote>
<pre>
<ins>template&lt;class T, class U&gt;</ins>
  <ins>concept <i>same-impl</i> = // exposition only</ins>
    <ins>is_same_v&lt;T, U&gt;;</ins>

template&lt;class T, class U&gt;
  concept Same = <del>is_same_v&lt;T, U&gt;</del><ins><i>same-impl</i>&lt;T, U&gt; &amp;&amp; <i>same-impl</i>&lt;U, T&gt;</ins>;
</pre>
<p>
-1- <ins>[<i>Note:</i></ins> <tt>Same&lt;T, U&gt;</tt> subsumes
<tt>Same&lt;U, T&gt;</tt> and vice versa.<ins>&mdash;<i>end note</i>]</ins>
</p>
</blockquote>
</li>
</ol>




</body>
</html>
