<!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 Prague</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 Prague</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2051R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2020-01-13 at 07:03:57 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="3194" href="#3194">3194</a><sup><a href="https://cplusplus.github.io/LWG/issue3194">(i)</a></sup>. <tt>ConvertibleTo</tt> prose does not match code</h3>
<p><b>Section:</b> 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hubert Tong  <b>Opened:</b> 2019-03-05 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#concept.convertible">active issues</a> in [concept.convertible].</p>
<p><b>View all other</b> <a href="lwg-index.html#concept.convertible">issues</a> in [concept.convertible].</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 prose in <a href="https://wg21.link/n4800">N4800</a> subclause  [concept.convertibleto] indicates 
that the requirement is for an expression of a particular type and value category to be both implicitly and explicitly 
convertible to some other type. However, for a type
</p>
<blockquote><pre>
struct A { A(const A&amp;) = delete; };
</pre></blockquote>
<p>
<tt>ConvertibleTo&lt;const A, A&gt;</tt> would be <tt>false</tt> despite the following being okay:
</p>
<blockquote><pre>
const A f();

A test() {
  static_cast&lt;A&gt;(f());
  return f();
}
</pre></blockquote>

<p><i>[2019-03-15 Priority set to 1 after reflector discussion]</i></p>


<p><i>[2019-07-14 Tim adds PR based on discussion in 2019-07-09 LWG telecon]</i></p>


<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4820">N4820</a>, and also resolves LWG <a href="lwg-active.html#3151">3151</a>.</p>

<ol>
<li><p>Modify  [concept.convertibleto] as indicated:</p>

<blockquote>
<p>
-1- The <tt>ConvertibleTo</tt> concept requires <del>an</del><ins>a glvalue</ins> expression of a particular type and
value category to be both implicitly and explicitly convertible to some other type. The implicit and explicit conversions
are required to produce equal results.
</p>

<pre>
template&lt;class From, class To&gt;
  concept ConvertibleTo =
    is_convertible_v&lt;From, To&gt; &amp;&amp;
    requires(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
      static_cast&lt;To&gt;(f());
    };
</pre>
<blockquote>
<p>
-2- Let <tt>test</tt> be the invented function:
</p>
<blockquote>
<pre>
To test(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
  return f();
}
</pre>
</blockquote>
<p>
for some types <tt>From</tt> and <tt>To</tt>, and let <tt>f</tt> be a function with no arguments and return type
<tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> such that <tt>f()</tt> is equality-preserving.
<tt>From</tt> and <tt>To</tt> model <tt>ConvertibleTo&lt;From, To&gt;</tt> only if:
</p>
<ol style="list-style-type:none">
<li><p>(2.1) &mdash; <tt>To</tt> is not an object or reference-to-object type, or <tt>static_cast&lt;To&gt;(f())</tt>
is equal to <tt>test(f)</tt>.</p></li>
<li><p>(2.2) &mdash; <tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> is not a reference-to-object type, or</p>
<ol style="list-style-type:none">
<li><p>(2.2.1) &mdash; If <tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> is an rvalue reference 
to a non const-qualified type, the resulting state of the object referenced by <tt>f()</tt> after either above expression is valid
but unspecified (16.5.5.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>).</p></li>
<li><p>(2.2.2) &mdash; Otherwise, the object referred to by <tt>f()</tt> is not modified by either above expression.</p></li>
</ol>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2019-09-23; Daniel adjusts wording to working draft changes]</i></p>

<p>
Due to the concept renaming caused by <a href="http://wg21.link/p1754r1">P1754R1</a> the proposed
wording is outdated and needs adjustments.
</p>
<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4830">N4830</a>, and also resolves LWG <a href="lwg-active.html#3151">3151</a>.</p>

<ol>
<li><p>Modify 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> as indicated:</p>

<blockquote>
<p>
-1- The <tt>convertible_to</tt> concept requires <del>an</del><ins>a glvalue</ins> expression of a particular type and
value category to be both implicitly and explicitly convertible to some other type. The implicit and explicit conversions
are required to produce equal results.
</p>

<pre>
template&lt;class From, class To&gt;
  concept convertible_to =
    is_convertible_v&lt;From, To&gt; &amp;&amp;
    requires(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
      static_cast&lt;To&gt;(f());
    };
</pre>
<blockquote>
<p>
-2- Let <tt>test</tt> be the invented function:
</p>
<blockquote>
<pre>
To test(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
  return f();
}
</pre>
</blockquote>
<p>
for some types <tt>From</tt> and <tt>To</tt>, and let <tt>f</tt> be a function with no arguments and return type
<tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> such that <tt>f()</tt> is equality-preserving.
<tt>From</tt> and <tt>To</tt> model <tt>convertible_to&lt;From, To&gt;</tt> only if:
</p>
<ol style="list-style-type:none">
<li><p>(2.1) &mdash; <tt>To</tt> is not an object or reference-to-object type, or <tt>static_cast&lt;To&gt;(f())</tt>
is equal to <tt>test(f)</tt>.</p></li>
<li><p>(2.2) &mdash; <tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> is not a reference-to-object type, or</p>
<ol style="list-style-type:none">
<li><p>(2.2.1) &mdash; If <tt><ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins></tt> is an rvalue reference 
to a non const-qualified type, the resulting state of the object referenced by <tt>f()</tt> after either above expression is valid
but unspecified (16.5.5.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>).</p></li>
<li><p>(2.2.2) &mdash; Otherwise, the object referred to by <tt>f()</tt> is not modified by either above expression.</p></li>
</ol>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2019-11-06 Tim updates PR based on discussion in Belfast LWG evening session]</i></p>

<p>
"glvalue" is incorrect because we want to allow testing <tt>convertible_to&lt;void, void&gt;</tt>. It's also less than clear
how the "expression" and "a particular type" in the first sentence correspond to the parameters of the concept.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4835">N4835</a>, and also resolves LWG <a href="lwg-active.html#3151">3151</a>.</p>

<ol>
<li><p>Modify 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> as indicated:</p>

<blockquote>
<p>
-1- The <tt>convertible_to</tt> concept <ins>for types <tt>From</tt> and <tt>To</tt></ins> requires an expression
<ins><tt>E</tt> such that <tt>decltype((E))</tt> is <tt>add_rvalue_reference_t&lt;From&gt;</tt></ins>
<del>of a particular type and value category</del> to be both implicitly and explicitly convertible to 
<del>some other type</del> <ins><tt>To</tt></ins>. The implicit and explicit conversions are required to produce equal results.
</p>

<pre>
template&lt;class From, class To&gt;
  concept convertible_to =
    is_convertible_v&lt;From, To&gt; &amp;&amp;
    requires(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
      static_cast&lt;To&gt;(f());
    };
</pre>
<blockquote>
<p>
-2- Let <ins><tt>FromR</tt> be <tt>add_rvalue_reference_t&lt;From&gt;</tt> and</ins> <tt>test</tt> be the invented function:
</p>
<blockquote>
<pre>
To test(From<ins>R</ins> (&amp;f)()) {
  return f();
}
</pre>
</blockquote>
<p>
for some types <tt>From</tt> and <tt>To</tt>, and let <tt>f</tt> be a function with no arguments and return type
<tt>From<ins>R</ins></tt> such that <tt>f()</tt> is equality-preserving.
<tt>From</tt> and <tt>To</tt> model <tt>convertible_to&lt;From, To&gt;</tt> only if:
</p>
<ol style="list-style-type:none">
<li><p>(2.1) &mdash; <tt>To</tt> is not an object or reference-to-object type, or <tt>static_cast&lt;To&gt;(f())</tt>
is equal to <tt>test(f)</tt>.</p></li>
<li><p>(2.2) &mdash; <tt>From<ins>R</ins></tt> is not a reference-to-object type, or</p>
<ol style="list-style-type:none">
<li><p>(2.2.1) &mdash; If <tt>From<ins>R</ins></tt> is an rvalue reference 
to a non const-qualified type, the resulting state of the object referenced by <tt>f()</tt> after either above expression is valid
but unspecified (16.5.5.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>).</p></li>
<li><p>(2.2.2) &mdash; Otherwise, the object referred to by <tt>f()</tt> is not modified by either above expression.</p></li>
</ol>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2019-11-09 Tim rephrased first sentence based on discussion in Belfast LWG Saturday session]</i></p>

<p><i>[Status to Tentatively ready after Belfast LWG Saturday session]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4835">N4835</a>, and also resolves LWG <a href="lwg-active.html#3151">3151</a>.</p>

<ol>
<li><p>Modify 18.4.4 <a href="https://wg21.link/concept.convertible">[concept.convertible]</a> as indicated:</p>

<blockquote>
<p>
-1- <ins>Given types <tt>From</tt> and <tt>To</tt> and an expression <tt>E</tt> such that <tt>decltype((E))</tt>
is <tt>add_rvalue_reference_t&lt;From&gt;</tt>, <tt>convertible_to&lt;From, To&gt;</tt></ins>
<del>The <tt>convertible_to</tt> concept</del> requires <ins><tt>E</tt></ins>
<del>an expression of a particular type and value category</del> to be both implicitly and explicitly convertible to 
<del>some other</del> type<ins> <tt>To</tt></ins>. The implicit and explicit conversions are required to produce equal results.
</p>

<pre>
template&lt;class From, class To&gt;
  concept convertible_to =
    is_convertible_v&lt;From, To&gt; &amp;&amp;
    requires(<ins>add_rvalue_reference_t&lt;</ins>From<ins>&gt;</ins> (&amp;f)()) {
      static_cast&lt;To&gt;(f());
    };
</pre>
<blockquote>
<p>
-2- Let <ins><tt>FromR</tt> be <tt>add_rvalue_reference_t&lt;From&gt;</tt> and</ins> <tt>test</tt> be the invented function:
</p>
<blockquote>
<pre>
To test(From<ins>R</ins> (&amp;f)()) {
  return f();
}
</pre>
</blockquote>
<p>
for some types <tt>From</tt> and <tt>To</tt>, and let <tt>f</tt> be a function with no arguments and return type
<tt>From<ins>R</ins></tt> such that <tt>f()</tt> is equality-preserving.
<tt>From</tt> and <tt>To</tt> model <tt>convertible_to&lt;From, To&gt;</tt> only if:
</p>
<ol style="list-style-type:none">
<li><p>(2.1) &mdash; <tt>To</tt> is not an object or reference-to-object type, or <tt>static_cast&lt;To&gt;(f())</tt>
is equal to <tt>test(f)</tt>.</p></li>
<li><p>(2.2) &mdash; <tt>From<ins>R</ins></tt> is not a reference-to-object type, or</p>
<ol style="list-style-type:none">
<li><p>(2.2.1) &mdash; If <tt>From<ins>R</ins></tt> is an rvalue reference 
to a non const-qualified type, the resulting state of the object referenced by <tt>f()</tt> after either above expression is valid
but unspecified (16.5.5.16 <a href="https://wg21.link/lib.types.movedfrom">[lib.types.movedfrom]</a>).</p></li>
<li><p>(2.2.2) &mdash; Otherwise, the object referred to by <tt>f()</tt> is not modified by either above expression.</p></li>
</ol>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3233" href="#3233">3233</a><sup><a href="https://cplusplus.github.io/LWG/issue3233">(i)</a></sup>. Broken requirements for <tt>shared_ptr</tt> converting constructors</h3>
<p><b>Section:</b> 20.11.3.1 <a href="https://wg21.link/util.smartptr.shared.const">[util.smartptr.shared.const]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-07-10 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.const">active issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</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>
Issue <a href="lwg-defects.html#2875">2875</a> added 20.11.3.1 <a href="https://wg21.link/util.smartptr.shared.const">[util.smartptr.shared.const]</a> paragraph 13:
<blockquote>
<i>Remarks</i>: When <tt>T</tt> is an array type, this constructor shall not participate in overload
resolution unless <tt>is_move_constructible_v&lt;D&gt;</tt> is <tt>true</tt>, the expression
<tt>d(p)</tt> is well-formed, and either <tt>T</tt> is <tt>U[N]</tt> and <tt>Y(*)[N]</tt> is
convertible to <tt>T*</tt>, or <tt>T</tt> is <tt>U[]</tt> and <tt>Y(*)[]</tt> is convertible to
<tt>T*</tt>. When <tt>T</tt> is not an array type, this constructor shall not participate in
overload resolution unless <tt>is_move_constructible_v&lt;D&gt;</tt> is <tt>true</tt>, the
expression <tt>d(p)</tt> is well-formed, and <tt>Y*</tt> is convertible to <tt>T*</tt>.
</blockquote>
which pertains to the four constructor overloads:
<blockquote><pre>
template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre></blockquote>
which is fine (ignoring for now that two occurrences of "this constructor" should read "these
constructors") for the two overloads with a template parameter <tt>Y</tt>, but not so much for the
two with no such template parameter.
</p>
<p>
MSVC ignores the constraints on <tt>Y</tt> for the overloads with no such template parameter,
whereas libstdc++ and libc++ seem to ignore <em>all</em> of the constraints for those overloads (See
<a href="https://gcc.godbolt.org/z/ECdop6">Compiler Explorer</a>). We should fix the broken wording,
ideally by requiring the MSVC interpretation - the <tt>nullptr_t</tt> constructors participate in
overload resolution only when <tt>is_movable_v&lt;D&gt;</tt> is <tt>true</tt> and <tt>d(p)</tt> is
well-formed - so concepts and traits that check constructibility are correct.
</p>

<p><i>[2019-11-17 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after six positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 20.11.3.1 <a href="https://wg21.link/util.smartptr.shared.const">[util.smartptr.shared.const]</a> as indicated:</p>

<blockquote>
<blockquote><pre>
template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
template&lt;class D&gt; shared_ptr(nullptr_t p, D d);
template&lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre></blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>is_move_constructible_v&lt;D&gt;</tt> is <tt>true</tt>, and
<tt>d(p)</tt> is a well-formed expression. For the first two overloads:</ins>
</p>
<ul>
  <li><p><ins>
    If <tt>T</tt> is an array type, then either <tt>T</tt> is <tt>U[N]</tt> and <tt>Y(*)[N]</tt> is
    convertible to <tt>T*</tt>, or <tt>T</tt> is <tt>U[]</tt> and <tt>Y(*)[]</tt> is convertible to
    <tt>T*</tt>.
  </ins></p></li>
  <li><p><ins>
    If <tt>T</tt> is not an array type, then <tt>Y*</tt> is convertible to <tt>T*</tt>.
  </ins></p></li>
</ul>
<p>
-9- <i><del>Requires</del><ins>Expects</ins>:</i> Construction of <tt>d</tt> and a deleter of type [&hellip;]
</p>
<p>[&hellip;]</p>
<p>
<del>-13- <i>Remarks:</i> When <tt>T</tt> is an array type, this constructor shall not participate
in overload resolution unless <tt>is_move_constructible_v&lt;D&gt;</tt> is <tt>true</tt>, the
expression <tt>d(p)</tt> is well-formed, and either <tt>T</tt> is <tt>U[N]</tt> and <tt>Y(*)[N]</tt>
is convertible to <tt>T*</tt>, or <tt>T</tt> is <tt>U[]</tt> and <tt>Y(*)[]</tt> is convertible to
<tt>T*</tt>. When <tt>T</tt> is not an array type, this constructor shall not participate in
overload resolution unless <tt>is_move_constructible_v&lt;D&gt;</tt> is <tt>true</tt>, the
expression <tt>d(p)</tt> is well-formed, and <tt>Y*</tt> is convertible to <tt>T*</tt>.</del>
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3254" href="#3254">3254</a><sup><a href="https://cplusplus.github.io/LWG/issue3254">(i)</a></sup>. Strike <tt>stop_token</tt>'s <tt>operator!=</tt></h3>
<p><b>Section:</b> 32.3.3 <a href="https://wg21.link/stoptoken">[stoptoken]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-08-06 <b>Last modified:</b> 2020-01-12</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 shiny new world of the future, we need not declare overloads of <tt>operator!=</tt> that 
<tt>return !(x == y);</tt> the rewrite rule in 12.4.1.2 <a href="https://wg21.link/over.match.oper">[over.match.oper]</a> para 3.4.3 
achieves the same effect. Consequently, we should not declare such unnecessary 
<tt>operator!=</tt> overloads. The synopsis of class <tt>stop_token</tt> in 32.3.3 <a href="https://wg21.link/stoptoken">[stoptoken]</a> 
declares exactly such an <tt>operator!=</tt> friend which should be struck.
</p>
<p><i>[01-2020 Moved to Tentatively Ready after 5 positive votes on the reflector.]</i></p>



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

<ol>
<li><p>Modify 32.3.3 <a href="https://wg21.link/stoptoken">[stoptoken]</a>, class <tt>stop_token</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  class stop_token {
  public:  
    [&hellip;]
    [[nodiscard]] friend bool operator==(const stop_token&amp; lhs, const stop_token&amp; rhs) noexcept;
    <del>[[nodiscard]] friend bool operator!=(const stop_token&amp; lhs, const stop_token&amp; rhs) noexcept;</del>
    friend void swap(stop_token&amp; lhs, stop_token&amp; rhs) noexcept;
  };
}
</pre>
</blockquote>

</li>

<li><p>Modify 32.3.3.3 <a href="https://wg21.link/stoptoken.cmp">[stoptoken.cmp]</a> and 32.3.3.4 <a href="https://wg21.link/stoptoken.special">[stoptoken.special]</a> as indicated:</p>

<blockquote>
<p>
<b>32.3.3.3 <ins>Non-member functions</ins><del>Comparisons</del> [stoptoken.<ins>nonmembers</ins><del>cmp</del>]</b>
</p>
<pre>
[[nodiscard]] bool operator==(const stop_token&amp; lhs, const stop_token&amp; rhs) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> <tt>true</tt> if <tt>lhs</tt> and <tt>rhs</tt> have ownership of the same stop 
state or if both <tt>lhs</tt> and <tt>rhs</tt> do not have ownership of a stop state; otherwise <tt>false</tt>.
</p>
</blockquote>
<pre>
<del>[[nodiscard]] bool operator!=(const stop_token&amp; lhs, const stop_token&amp; rhs) noexcept;</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Returns:</i> <tt>!(lhs==rhs)</tt>.</del>
</p>
</blockquote>
<p>
<del><b>32.3.3.4 Specialized algorithms [stoptoken.special]</b></del>
</p>
<pre>
friend void swap(stop_token&amp; x, stop_token&amp; y) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to: <tt>x.swap(y)</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3264" href="#3264">3264</a><sup><a href="https://cplusplus.github.io/LWG/issue3264">(i)</a></sup>. <tt>sized_range</tt> and <tt>ranges::size</tt> redundantly use <tt>disable_sized_range</tt></h3>
<p><b>Section:</b> 24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-08-26 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>disable_sized_range</tt> (24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a>) is an opt-out trait that users may
specialize when their <tt>range</tt> type conforms to the syntax of <tt>sized_range</tt> but not its
semantics, or when the type is so poorly suited to the Standard Library that even testing the
validity of the expressions <tt>r.size()</tt> or <tt>size(r)</tt> for a range <tt>r</tt> is
impossible. The library inspects <tt>disable_sized_range</tt> in two places. (1) In the definition of
the <tt>sized_range</tt> concept:
<blockquote><pre>
template&lt;class T&gt;
  concept sized_range =
    range&lt;T&gt; &amp;&amp;
    !disable_sized_range&lt;remove_cvref_t&lt;T&gt;&gt; &amp;&amp;
    requires(T&amp; t) { ranges::size(t); };
</pre></blockquote>
If the pertinent specialization of <tt>disable_sized_range</tt> is <tt>true</tt>, we avoid checking
the validity of the expression <tt>ranges::size(t)</tt> in the <i>requires-expression</i>.
(2) In the definition of the <tt>ranges::size</tt> CPO itself (24.3.9 <a href="https://wg21.link/range.prim.size">[range.prim.size]</a>),
the validity of the expressions <tt><i>decay-copy</i>(E.size())</tt> and
<tt><i>decay-copy</i>(size(E))</tt> is not checked if the pertinent specialization of
<tt>disable_sized_range</tt> is <tt>true</tt>.
</p><p>
<tt>disable_sized_range</tt> is effectively checked <em>twice</em> when evaluating
<tt>sized_range</tt>. This redundancy could be forgiven, if it did not permit the existence of
non-<tt>sized_range</tt>s for which <tt>ranges::size</tt> returns a valid size:
<blockquote><pre>
struct mytype {};
using A = mytype[42];

template &lt;&gt;
constexpr bool std::ranges::disable_sized_range&lt;A&gt; = true;

static_assert(std::ranges::range&lt;A&gt;);
static_assert(!std::ranges::sized_range&lt;A&gt;);
static_assert(std::ranges::size(A{}) == 42);

struct myrange {
    constexpr int* begin() const { return nullptr; }
    constexpr int* end() const { return nullptr; }
};

template &lt;&gt;
constexpr bool std::ranges::disable_sized_range&lt;myrange&gt; = true;

static_assert(std::ranges::range&lt;myrange&gt;);
static_assert(!std::ranges::sized_range&lt;myrange&gt;);
static_assert(std::ranges::size(myrange{}) == 0);
</pre></blockquote>
We should remove this gap between <tt>ranges::size</tt> and <tt>sized_range</tt> by checking
<tt>disable_sized_range</tt> only in the definition of <tt>ranges::size</tt>, and continuing to rely
on the validity of <tt>ranges::size</tt> in the <tt>sized_range</tt> concept.
</p>

<p><i>[2019-09-14 Priority set to 1 based on reflector discussion]</i></p>

<p><i>[2019-11 Wednesday night issue processing in Belfast.]</i></p>

<p>Status to Ready</p>


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

<ol>
<li><p>Modify 24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a> as follows:</p>

<blockquote><pre>
template&lt;class T&gt;
  concept sized_range =
    range&lt;T&gt; &amp;&amp;
    <del>!disable_sized_range&lt;remove_cvref_t&lt;T&gt;&gt; &amp;&amp;</del>
    requires(T&amp; t) { ranges::size(t); };
</pre></blockquote>
</li>
</ol>





<hr>
<h3><a name="3280" href="#3280">3280</a><sup><a href="https://cplusplus.github.io/LWG/issue3280">(i)</a></sup>. View converting constructors can cause constraint recursion and are unneeded</h3>
<p><b>Section:</b> 24.7.4.2 <a href="https://wg21.link/range.filter.view">[range.filter.view]</a>, 24.7.5.2 <a href="https://wg21.link/range.transform.view">[range.transform.view]</a>, 24.7.6.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>, 24.7.10.2 <a href="https://wg21.link/range.join.view">[range.join.view]</a>, 24.7.11.2 <a href="https://wg21.link/range.split.view">[range.split.view]</a>, 24.7.14.2 <a href="https://wg21.link/range.reverse.view">[range.reverse.view]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-09 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>1
</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 following program fails to compile:
</p>
<blockquote><pre>
#include &lt;ranges&gt;

int main() {
  namespace ranges = std::ranges;
  int a[] = {1, 7, 3, 6, 5, 2, 4, 8};
  auto r0 = ranges::view::reverse(a);
  auto is_even = [](int i) { return i % 2 == 0; };
  auto r1 = ranges::view::filter(r0, is_even);
  int sum = 0;
  for (auto i : r1) {
    sum += i;
  }
  return sum - 20;
}
</pre></blockquote>
<p>
The problem comes from constraint recursion, caused by the following constructor:
</p>
<blockquote><pre>
template&lt;viewable_range R&gt;
  requires bidirectional_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr explicit reverse_view(R&amp;&amp; r);
</pre></blockquote>
<p>
This constructor owes its existence to class template argument deduction; it is the constructor 
we intend to use to resolve <tt>reverse_view{r}</tt>, which (in accordance to the deduction guide) 
will construct an object of type <tt>reverse_view&lt;all_view&lt;decltype(r)&gt;&gt;</tt>.
<p/>
However, we note that <tt>all_view&lt;R&gt;</tt> is always one of:
</p>
<ul>
<li><p><tt>decay_t&lt;R&gt;</tt></p></li>
<li><p><tt>ref_view&lt;remove_reference_t&lt;R&gt;&gt;</tt></p></li>
<li><p><tt>subrange&lt;iterator_t&lt;R&gt;, sentinel_t&lt;R&gt;, [sized?]&gt;</tt></p></li>
</ul>
<p>
In all cases, there is a conversion from <tt>r</tt> to the destination type. As a result, the 
following non-template <tt>reverse_view</tt> constructor can fulfill the duty that the above 
constructor was meant to fulfill, and does <em>not</em> cause constraint recursion:
</p>
<blockquote><pre>
constexpr explicit reverse_view(V r);
</pre></blockquote>
<p>
In short, the problematic constructor can simply be removed with no negative impact on the design. 
And the similar constructors from the other range adaptors should similarly be stricken.
<p/>
Suggested priority P1. The view types are unusable without this change.
<p/>
This proposed resolution has been implemented in range-v3 and has been shipping for some time.
</p>

<p><i>[2019-10 Priority set to 1 after reflector discussion]</i></p>

<p><i>[2019-10 Status set to ready Wednesday night discussion in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.7.4.2 <a href="https://wg21.link/range.filter.view">[range.filter.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, indirect_unary_predicate&lt;iterator_t&lt;V&gt;&gt; Pred&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;Pred&gt;
  class filter_view : public view_interface&lt;filter_view&lt;V, Pred&gt;&gt; {
  [&hellip;]
  public:
    filter_view() = default;
    constexpr filter_view(V base, Pred pred);
    <del>template&lt;input_range R&gt;
      requires viewable_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
    constexpr filter_view(R&amp;&amp; r, Pred pred);</del>
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;input_range R&gt;
  requires viewable_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr filter_view(R&amp;&amp; r, Pred pred);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt> 
and initializes <tt>pred_</tt> with <tt>std::move(pred)</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.5.2 <a href="https://wg21.link/range.transform.view">[range.transform.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
    regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt;
  class transform_view : public view_interface&lt;transform_view&lt;V, F&gt;&gt; {
  private:
    [&hellip;]
  public:
    transform_view() = default;
    constexpr transform_view(V base, F fun);
    <del>template&lt;input_range R&gt;
      requires viewable_range&lt;R> &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
    constexpr transform_view(R&amp;&amp; r, F fun);</del>
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;input_range R&gt;
  requires viewable_range&lt;R> &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr transform_view(R&amp;&amp; r, F fun);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt> 
and <tt>fun_</tt> with <tt>std::move(fun)</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.6.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
  class take_view : public view_interface&lt;take_view&lt;V&gt;&gt; {
  private:
    [&hellip;]
  public:
    take_view() = default;
    constexpr take_view(V base, range_difference_t&lt;V&gt; count);
    <del>template&lt;viewable_range R&gt;
      requires constructible_from&lt;V, all_view&lt;R&gt;&gt;
    constexpr take_view(R&amp;&amp; r, range_difference_t&lt;V&gt; count);</del>
    [&hellip;]
  };
[&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;viewable_range R&gt;
  requires constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr take_view(R&amp;&amp; r, range_difference_t&lt;V&gt; count);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt> 
and <tt>count_</tt> with <tt>count</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.10.2 <a href="https://wg21.link/range.join.view">[range.join.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V&gt;
    requires view&lt;V&gt; &amp;&amp; input_range&lt;range_reference_t&lt;V&gt;&gt; &amp;&amp;
             (is_reference_v&lt;range_reference_t&lt;V&gt;&gt; ||
             view&lt;range_value_t&lt;V&gt;&gt;)
  class join_view : public view_interface&lt;join_view&lt;V&gt;&gt; {
  private:
    [&hellip;]
  public:
    join_view() = default;
    constexpr explicit join_view(V base);
    <del>template&lt;input_range R&gt;
      requires viewable_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
    constexpr explicit join_view(R&amp;&amp; r);</del>
    [&hellip;]
  };
[&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;input_range R&gt;
  requires viewable_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr explicit join_view(R&amp;&amp; r);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.11.2 <a href="https://wg21.link/range.split.view">[range.split.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
[&hellip;]
  template&lt;input_range V, forward_range Pattern&gt;
    requires view&lt;V&gt; &amp;&amp; view&lt;Pattern&gt; &amp;&amp;
             indirectly_comparable&lt;iterator_t&lt;V&gt;, iterator_t&lt;Pattern&gt;, ranges::equal_to&gt; &amp;&amp;
             (forward_range&lt;V&gt; || <i>tiny-range</i>&lt;Pattern&gt;)
  class split_view : public view_interface&lt;split_view&lt;V, Pattern&gt;&gt; {
  private:
    [&hellip;]
  public:
    split_view() = default;
    constexpr split_view(V base, Pattern pattern);
    <del>template&lt;input_range R, forward_range P&gt;
      requires constructible_from&lt;V, all_view&lt;R&gt;&gt; &amp;&amp;
               constructible_from&lt;Pattern, all_view&lt;P&gt;&gt;
    constexpr split_view(R&amp;&amp; r, P&amp;&amp; p);</del>
    [&hellip;]
  };
[&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;input_range R, forward_range P&gt;
  requires constructible_from&lt;V, all_view&lt;R&gt;&gt; &amp;&amp;
           constructible_from&lt;Pattern, all_view&lt;P&gt;&gt;
constexpr split_view(R&amp;&amp; r, P&amp;&amp; p);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt>, 
and <tt>pattern_</tt> with <tt>views::all(std::forward&lt;P&gt;(p))</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 24.7.14.2 <a href="https://wg21.link/range.reverse.view">[range.reverse.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
    requires bidirectional_range&lt;V&gt;
  class reverse_view : public view_interface&lt;reverse_view&lt;V&gt;&gt; {
  private:
    [&hellip;]
  public:
    reverse_view() = default;
    constexpr explicit reverse_view(V r);
    <del>template&lt;viewable_range R&gt;
      requires bidirectional_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
    constexpr explicit reverse_view(R&amp;&amp; r);</del>
    [&hellip;]
  };
[&hellip;]
}
</pre>
[&hellip;]
<pre>
<del>template&lt;viewable_range R&gt;
  requires bidirectional_range&lt;R&gt; &amp;&amp; constructible_from&lt;V, all_view&lt;R&gt;&gt;
constexpr explicit reverse_view(R&amp;&amp; r);</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Effects:</i> Initializes <tt>base_</tt> with <tt>views::all(std::forward&lt;R&gt;(r))</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3281" href="#3281">3281</a><sup><a href="https://cplusplus.github.io/LWG/issue3281">(i)</a></sup>. Conversion from <tt><i>pair-like</i></tt> types to <tt>subrange</tt> is a silent semantic promotion</h3>
<p><b>Section:</b> 24.5.3 <a href="https://wg21.link/range.subrange">[range.subrange]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-10 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.subrange">active issues</a> in [range.subrange].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.subrange">issues</a> in [range.subrange].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Just because a <tt>pair</tt> is holding two iterators, it doesn't mean those two iterators denote a 
valid range. Implicitly converting such <tt><i>pair-like</i></tt> types to a <tt>subrange</tt> is 
dangerous and should be disallowed.
<p/>
Suggested priority P1.
<p/>
Implementation experience: range-v3's subrange lacks these constructors.
</p>

<p><i>[2019-10 Priority set to 1 and status to LEWG after reflector discussion]</i></p>

<p><i>[2019-11 Status to Ready after LWG discussion Friday in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.5.3 <a href="https://wg21.link/range.subrange">[range.subrange]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
[&hellip;]
  <del>template&lt;class T, class U, class V&gt;
    concept <i>pair-like-convertible-to</i> = <i>// exposition only</i>
      !range&lt;T&gt; &amp;&amp; <i>pair-like</i>&lt;remove_reference_t&lt;T&gt;&gt; &amp;&amp;
      requires(T&amp;&amp; t) {
        { get&lt;0&gt;(std::forward&lt;T&gt;(t)) } -&gt; convertible_to&lt;U&gt;;
        { get&lt;1&gt;(std::forward&lt;T&gt;(t)) } -&gt; convertible_to&lt;V&gt;;
      };</del>
[&hellip;]
  template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S = I, subrange_kind K =
           sized_sentinel_for&lt;S, I&gt; ? subrange_kind::sized : subrange_kind::unsized&gt;
    requires (K == subrange_kind::sized || !sized_sentinel_for&lt;S, I&gt;)
  class subrange : public view_interface&lt;subrange&lt;I, S, K&gt;&gt; {
  private:
    [&hellip;]
  public:
    [&hellip;]
    <del>template&lt;<i>not-same-as</i>&lt;subrange&gt; PairLike&gt;
      requires <i>pair-like-convertible-to</i>&lt;PairLike, I, S&gt;
    constexpr subrange(PairLike&amp;&amp; r) requires (!StoreSize)
      : subrange{std::get&lt;0&gt;(std::forward&lt;PairLike&gt;(r)),
                 std::get&lt;1&gt;(std::forward&lt;PairLike&gt;(r))}
    {}
    template&lt;<i>pair-like-convertible-to</i>&lt;I, S&gt; PairLike&gt;
    constexpr subrange(PairLike&amp;&amp; r, <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n)
      requires (K == subrange_kind::sized)
      : subrange{std::get&lt;0&gt;(std::forward&lt;PairLike&gt;(r)),
                 std::get&lt;1&gt;(std::forward&lt;PairLike&gt;(r)), n}
    {}</del>
  [&hellip;]
  };
[&hellip;]
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3284" href="#3284">3284</a><sup><a href="https://cplusplus.github.io/LWG/issue3284">(i)</a></sup>. <tt>random_access_iterator</tt> semantic constraints accidentally promote difference type
 using unary negate</h3>
<p><b>Section:</b> 23.3.4.13 <a href="https://wg21.link/iterator.concept.random.access">[iterator.concept.random.access]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-10 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.concept.random.access">issues</a> in [iterator.concept.random.access].</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>
23.3.4.13 <a href="https://wg21.link/iterator.concept.random.access">[iterator.concept.random.access]</a>/p2.7 says:
</p>
<blockquote><p>
<tt>(b += -n)</tt> is equal to <tt>a</tt>
</p></blockquote>
<p>
Unary minus can do integer promotion. That is not the intent here.
</p>

<p><i>[2019-10-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after five positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 23.3.4.13 <a href="https://wg21.link/iterator.concept.random.access">[iterator.concept.random.access]</a> as indicated:</p>

<blockquote>
<p>
-2- Let <tt>a</tt> and <tt>b</tt> be valid iterators of type <tt>I</tt> such that <tt>b</tt> 
is reachable from <tt>a</tt> after <tt>n</tt> applications of <tt>++a</tt>, let <tt>D</tt> be
<tt>iter_difference_t&lt;I&gt;</tt>, and let <tt>n</tt> denote a value of type <tt>D</tt>. 
<tt>I</tt> models <tt>random_access_iterator</tt> only if:
</p>
<ol style="list-style-type: none">
<li><p>(2.1) &mdash; <tt>(a += n)</tt> is equal to <tt>b</tt>.</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(2.7) &mdash; <tt>(b += <ins>D(</ins>-n<ins>)</ins>)</tt> is equal to <tt>a</tt>.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3285" href="#3285">3285</a><sup><a href="https://cplusplus.github.io/LWG/issue3285">(i)</a></sup>. The type of a customization point object shall satisfy <tt>semiregular</tt></h3>
<p><b>Section:</b> 16.4.2.2.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-10 <b>Last modified:</b> 2019-12-02</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>
We should be testing the un-<i>cv</i>-qualified type of a customization point object.
</p>

<p><i>[2019-10-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after seven positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 16.4.2.2.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a> as indicated:</p>

<blockquote>
<p>
-2- The type of a customization point object <ins>ignoring <i>cv</i>-qualifiers</ins> shall 
model <tt>semiregular</tt> (18.6 <a href="https://wg21.link/concepts.object">[concepts.object]</a>).
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3286" href="#3286">3286</a><sup><a href="https://cplusplus.github.io/LWG/issue3286">(i)</a></sup>. <tt>ranges::size</tt> is not required to be valid after a call to <tt>ranges::begin</tt> on an input range</h3>
<p><b>Section:</b> 24.7.6.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>, 24.5.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> Eric Niebler <b>Opened:</b> 2019-09-10 <b>Last modified:</b> 2019-12-02</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>
On an input (but not forward) range, <tt>begin(rng)</tt> is not required to be an equality-preserving 
expression (24.4.2 <a href="https://wg21.link/range.range">[range.range]</a>/3.3). If the range is <em>also</em> sized, then it is not valid 
to call <tt>size(rng)</tt> after <tt>begin(rng)</tt> (24.4.3 <a href="https://wg21.link/range.sized">[range.sized]</a>/2.2). In several 
places in the ranges clause, this precondition is violated. A trivial re-expression of the effects 
clause fixes the problem.
</p>

<p><i>[2019-10-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after seven positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 24.7.6.2 <a href="https://wg21.link/range.take.view">[range.take.view]</a>, class template <tt>take_view</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;view V&gt;
  class take_view : public view_interface&lt;take_view&lt;V&gt;&gt; {
  private:
    [&hellip;]
  public:
    [&hellip;]
    constexpr auto begin() requires (!<i>simple-view</i>&lt;V&gt;) {
      if constexpr (sized_range&lt;V&gt;) {
        if constexpr (random_access_range&lt;V&gt;)
          return ranges::begin(base_);
        else <ins>{
          auto sz = size();</ins>
          return counted_iterator{ranges::begin(base_), <del>size()</del><ins>sz</ins>};
        <ins>}</ins>
      } else
        return counted_iterator{ranges::begin(base_), count_};
    }

    constexpr auto begin() const requires range&lt;const V&gt; {
      if constexpr (sized_range&lt;const V&gt;) {
        if constexpr (random_access_range&lt;const V&gt;)
          return ranges::begin(base_);
        else <ins>{
          auto sz = size();</ins>
          return counted_iterator{ranges::begin(base_), <del>size()</del><ins>sz</ins>};
        <ins>}</ins>
      } else
        return counted_iterator{ranges::begin(base_), count_};
    }
    
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 24.5.3.1 <a href="https://wg21.link/range.subrange.ctor">[range.subrange.ctor]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;<i>not-same-as</i>&lt;subrange&gt; R&gt;
  requires forwarding-range&lt;R&gt; &amp;&amp;
    convertible_to&lt;iterator_t&lt;R&gt;, I&gt; &amp;&amp; convertible_to&lt;sentinel_t&lt;R&gt;, S&gt;
constexpr subrange(R&amp;&amp; r) requires (!StoreSize || sized_range&lt;R&gt;);
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to:
<ol style="list-style-type: none">
<li><p>(6.1) &mdash; If <tt>StoreSize</tt> is <tt>true</tt>, <tt>subrange{<del>ranges::begin(r), 
ranges::end(r)</del><ins>r</ins>, ranges::size(r)}</tt>.</p></li>
<li><p>(6.2) &mdash; Otherwise, <tt>subrange{ranges::begin(r), ranges::end(r)}</tt>.</p></li>
</ol>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3291" href="#3291">3291</a><sup><a href="https://cplusplus.github.io/LWG/issue3291">(i)</a></sup>. <tt>iota_view::iterator</tt> has the wrong <tt>iterator_category</tt></h3>
<p><b>Section:</b> 24.6.3.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-13 <b>Last modified:</b> 2019-12-02</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 old way of looking at the world, forward iterators need to return real references. Since 
dereferencing <tt>iota_view</tt>'s iterators returns by value, it cannot be a C++17 forward 
iterator. (It can, however, be a C++20 <tt>forward_iterator</tt>.) However, <tt>iota_view</tt>'s 
iterator has an <tt>iterator_category</tt> that (sometimes) falsely claims that it is forward or 
better (depending on the properties of the <tt>weakly_incrementable</tt> type it wraps).
</p>

<p><i>[2019-10-19 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 24.6.3.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;class W, class Bound&gt;
  struct iota_view&lt;W, Bound&gt;::iterator {
  private:
    [&hellip;]
  public:
    using iterator_c<ins>oncept</ins><del>ategory</del> = <i>see below</i>;
    <ins>using iterator_category = input_iterator_tag;</ins>
    using value_type = W;
    using difference_type = <i>IOTA-DIFF-T</i>(W);
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
<p>
-1- <tt>iterator::iterator_c<ins>oncept</ins><del>ategory</del></tt> is defined as follows:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; If <tt>W</tt> models <tt><i>advanceable</i></tt>, then 
<tt>iterator_c<ins>oncept</ins><del>ategory</del></tt> is <tt>random_access_iterator_tag</tt>.</p></li>
<li><p>(1.2) &mdash; Otherwise, if <tt>W</tt> models <tt><i>decrementable</i></tt>, then 
<tt>iterator_c<ins>oncept</ins><del>ategory</del></tt> is <tt>bidirectional_iterator_tag</tt>.</p></li>
<li><p>(1.3) &mdash; Otherwise, if <tt>W</tt> models <tt>incrementable</tt>, then 
<tt>iterator_c<ins>oncept</ins><del>ategory</del></tt> is <tt>forward_iterator_tag</tt>.</p></li>
<li><p>(1.4) &mdash; Otherwise, <tt>iterator_c<ins>oncept</ins><del>ategory</del></tt> is 
<tt>input_iterator_tag</tt>.</p></li>
</ol>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="3292" href="#3292">3292</a><sup><a href="https://cplusplus.github.io/LWG/issue3292">(i)</a></sup>. <tt>iota_view</tt> is under-constrained</h3>
<p><b>Section:</b> 24.6.3.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2019-09-13 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://wg21.link/p1207r4">P1207R4</a> changed <tt>weakly_incrementable</tt> from requiring 
<tt>semiregular</tt> to requiring <tt>default_constructible &amp;&amp; movable</tt>.
<p/>
<tt>iota_view</tt> currently is specified to require that <tt>W</tt> be just <tt>weakly_incrementable</tt>. 
But we have to copy the <tt>W</tt> from the view into its iterator and also in <tt>operator*()</tt> to 
return a <tt>W</tt>.
<p/>
The shortest resolution is just to add "<tt> &amp;&amp; semiregular&lt;W&gt;</tt>" to the class 
constraints.
</p>
<p><i>[Status to ready after discussion Friday morning in Belfast]</i></p>



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

<ol>
<li><p>Modify 24.6.3.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a> as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  template&lt;weakly_incrementable W, semiregular Bound = unreachable_sentinel_t&gt;
    requires <i>weakly-equality-comparable-with</i>&lt;W, Bound&gt; <ins>&amp;&amp; semiregular&lt;W&gt;</ins>
  class iota_view : public view_interface&lt;iota_view&lt;W, Bound&gt; {
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>

</li>

</ol>





<hr>
<h3><a name="3294" href="#3294">3294</a><sup><a href="https://cplusplus.github.io/LWG/issue3294">(i)</a></sup>. <tt>zoned_time</tt> deduction guides misinterprets <tt>string</tt>/<tt>char*</tt></h3>
<p><b>Section:</b> 27.11.7.1 <a href="https://wg21.link/time.zone.zonedtime.overview">[time.zone.zonedtime.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-09-14 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#time.zone.zonedtime.overview">issues</a> in [time.zone.zonedtime.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>
The current deduction guide for <code>zoned_time</code> for the following declarations
</p>
<blockquote>
<pre>
zoned_time zpc("America/New_York", std::chrono::system_clock::now());
zoned_time zps(std::string("America/New_York"), std::chrono::system_clock::now());
</pre>
</blockquote>
<p>
will attempt to produce a <code>zoned_time</code> instance with <code>const char*</code> 
(for <tt>zpc</tt>) and with <code>std::string</code> (for <tt>zps</tt>), respectively, 
as the deduced type for the <tt>TimeZonePtr</tt> template parameter. This is caused by 
the fact that the unconstrained <code>TimeZonePtr</code> deduction guide template will 
produce better candidates and will be selected by overload resolution.
<p/>
The proposed resolution merges the deduction of the 
<code>std::string_view</code>/<code>TimeZonePtr</code> deduction guides
into one guide, that deduces <code>const time_zone*</code> for any type
convertible to <code>string_view</code>. This is necessary to override
the deduction from <code>TimeZonePtr</code> constructor candidates.
<p/>
In addition, we disable the deduction from <code>string_view</code>
constructors, that would produce better candidates than the deduction guides
and create <code>zoned_time</code> instances with durations coarser than
<code>seconds</code> (causing similar issue as LWG <a href="lwg-defects.html#3232">3232</a>):
</p>
<blockquote>
<pre>
std::chrono::local_time&lt;hours&gt; lh(10h);
std::chrono::zoned_time zt1("Europe/Helsinki", lh);
std::chrono::zoned_time zt2(std::string("Europe/Helsinki"), lh);
std::chrono::zoned_time zt3(std::string_view("Europe/Helsinki"), lh);
</pre>
</blockquote>
<p>
Without disabling the deduction from the <code>string_view</code>
constructor, the type of the <code>zt3</code> variable would be deduced to 
<code>zoned_time&lt;hours&gt;</code>, with the proposed change the types
of the variables <code>zt1</code>, <code>zt2</code>, and <code>zt3</code> 
are consistently deduced as <code>zoned_time&lt;seconds&gt;</code>.
<p/>
Finally, the wording eliminates the unnecessary <code>zoned_time&lt;Duration&gt;</code> 
guide (covered by <code>zoned_time&lt;Duration, TimeZonePtr2&gt;</code>).
<p/>
The change was implemented in the example implementation. The dedicated
test can be found 
<a href="https://github.com/HowardHinnant/date/blob/master/test/tz_test/zoned_time_deduction.pass.cpp">here</a>.
</p>

<p><i>[2019-10-31 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after five positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 27.11.7.1 <a href="https://wg21.link/time.zone.zonedtime.overview">[time.zone.zonedtime.overview]</a>, class template <tt>zoned_time</tt> 
synopsis, as indicated:</p>

<blockquote>
<blockquote>
<pre>
namespace std::chrono {
  [&hellip;]
  zoned_time() -&gt; zoned_time&lt;seconds&gt;;
  
  template&lt;class Duration&gt;
    zoned_time(sys_time&lt;Duration&gt;)
      -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;;
      
  <ins>template&lt;class TimeZonePtrOrName&gt;
    using <i>time-zone-representation</i> =
      conditional_t&lt;is_convertible_v&lt;TimeZonePtrOrName, string_view&gt;, 
        const time_zone*,
        remove_cv_ref&lt;TimeZonePtrOrName&gt;&gt;; <i>// exposition only</i>

  template&lt;class TimeZonePtrOrName&gt;
    zoned_time(TimeZonePtrOrName&amp;&amp;)
      -&gt; zoned_time&lt;seconds, <i>time-zone-representation</i>&lt;TimeZonePtr&gt;&gt;;</ins>
  
  template&lt;class TimeZonePtr<ins>OrName</ins>, class Duration&gt;
    zoned_time(TimeZonePtr<ins>OrName&amp;&amp;</ins>, sys_time&lt;Duration&gt;)
      -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;, 
        <ins><i>time-zone-representation</i>&lt;</ins>TimeZonePtr<ins>OrName&gt;</ins>&gt;;
  
  template&lt;class TimeZonePtr<ins>OrName</ins>, class Duration&gt;
    zoned_time(TimeZonePtr<ins>OrName&amp;&amp;</ins>, local_time&lt;Duration&gt;, choose = choose::earliest)
      -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;, 
        <ins><i>time-zone-representation</i>&lt;</ins>TimeZonePtr<ins>OrName&gt;</ins>&gt;;
  
  <del>template&lt;class TimeZonePtr, class Duration&gt;
    zoned_time(TimeZonePtr, zoned_time&lt;Duration&gt;, choose = choose::earliest)
      -&gt;> zoned_time&lt;common_type_t&lt;Duration, seconds&gt;, TimeZonePtr&gt;;
  
  zoned_time(string_view) -&gt; zoned_time&lt;seconds&gt;;

  template&lt;class Duration&gt;
    zoned_time(string_view, sys_time&lt;Duration&gt;)
      -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;;
  
  template&lt;class Duration&gt;
    zoned_time(string_view, local_time&lt;Duration&gt;, choose = choose::earliest)
      -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;;</del>
  
  template&lt;class Duration, class TimeZonePtr<ins>OrName</ins>, class TimeZonePtr2&gt;
    zoned_time(TimeZonePtr<ins>OrName&amp;&amp;</ins>, zoned_time&lt;Duration, TimeZonePtr2&gt;, choose = choose::earliest)
     -&gt; zoned_time&lt;Duration, <ins><i>time-zone-representation</i>&lt;</ins>TimeZonePtr<ins>OrName&gt;</ins>&gt;;
}
</pre>
</blockquote>
<p>
-1- <tt>zoned_time</tt> represents a logical pairing of a <tt>time_zone</tt> and a <tt>time_point</tt> 
with precision <tt>Duration</tt>. <tt>zoned_time&lt;Duration&gt;</tt> maintains the invariant that it 
always refers to a valid time zone and represents a point in time that exists and is not ambiguous in 
that time zone.
<p/>
-2- If <tt>Duration</tt> is not a specialization of <tt>chrono::duration</tt>, the program is ill-formed.
<p/>
<ins>-?- Every constructor of <tt>zoned_time</tt> that accepts a <tt>string_view</tt> as first parameter 
does not participate in class template argument deduction (12.4.1.8 <a href="https://wg21.link/over.match.class.deduct">[over.match.class.deduct]</a>).</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3296" href="#3296">3296</a><sup><a href="https://cplusplus.github.io/LWG/issue3296">(i)</a></sup>. Inconsistent default argument for <tt>basic_regex&lt;&gt;::assign</tt></h3>
<p><b>Section:</b> 30.8 <a href="https://wg21.link/re.regex">[re.regex]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Mark de Wever <b>Opened:</b> 2019-09-16 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.regex">active issues</a> in [re.regex].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.regex">issues</a> in [re.regex].</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 declaration of the overload of <tt>basic_regex&lt;&gt;::assign(const charT* p, size_t len, flag_type f)</tt>
has an inconsistent default argument for the <tt>flag_type f</tt> parameter.
<p/>
30.8 <a href="https://wg21.link/re.regex">[re.regex]</a> p3:
</p>
<blockquote><pre>
basic_regex&amp; assign(const charT* p, size_t len, flag_type f);
</pre></blockquote>
<p>
30.8.2 <a href="https://wg21.link/re.regex.assign">[re.regex.assign]</a> before p12:
</p>
<blockquote><pre>
basic_regex&amp; assign(const charT* ptr, size_t len, flag_type f = regex_constants::ECMAScript);
</pre></blockquote>
<p>
Since all other overloads have a default argument in both 30.8 <a href="https://wg21.link/re.regex">[re.regex]</a> and
30.8.2 <a href="https://wg21.link/re.regex.assign">[re.regex.assign]</a> I propose to add a default argument for this overload
in the declaration in 30.8 <a href="https://wg21.link/re.regex">[re.regex]</a>.
<p/>
It should be pointed out that there exists implementation divergence due to the current
wording state: libc++ and libstdc++ do <em>not</em> implement the default argument.
The MS STL library <em>does</em> have the default argument.
</p>

<p><i>[2019-10-31 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after six positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 30.8 <a href="https://wg21.link/re.regex">[re.regex]</a>, class template <tt>basic_regex</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 30.8.2 <a href="https://wg21.link/re.regex.assign">[re.regex.assign]</a>, assign</i>
[&hellip;]
basic_regex&amp; assign(const charT* ptr, flag_type f = regex_constants::ECMAScript);
basic_regex&amp; assign(const charT* p, size_t len, flag_type f <ins>= regex_constants::ECMAScript</ins>);
template&lt;class string_traits, class A&gt;
  basic_regex&amp; assign(const basic_string&lt;charT, string_traits, A&gt;&amp; s,
                      flag_type f = regex_constants::ECMAScript);
template&lt;class InputIterator&gt;
  basic_regex&amp; assign(InputIterator first, InputIterator last,
                      flag_type f = regex_constants::ECMAScript);
basic_regex&amp; assign(initializer_list&lt;charT&gt;,
                    flag_type = regex_constants::ECMAScript);
[&hellip;]
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3299" href="#3299">3299</a><sup><a href="https://cplusplus.github.io/LWG/issue3299">(i)</a></sup>. Pointers don't need customized iterator behavior</h3>
<p><b>Section:</b> 23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a>, 23.3.3.2 <a href="https://wg21.link/iterator.cust.swap">[iterator.cust.swap]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-10-07 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.cust.move">active issues</a> in [iterator.cust.move].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.cust.move">issues</a> in [iterator.cust.move].</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>
It is not intentional design that users may customize the behavior of
<tt>ranges::iter_move</tt> (23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a>) and
<tt>ranges::iter_swap</tt> (23.3.3.2 <a href="https://wg21.link/iterator.cust.swap">[iterator.cust.swap]</a>)  for pointers to program-defined
type by defining e.g. <tt>iter_move(my_type*)</tt> or <tt>iter_swap(my_type*, my_type*)</tt> in a
namespace associated with <tt>my_type</tt>. The intent of customization points is that users may
define behavior for types they define, not that users may mess with the well-defined semantics for
existing types like pointers.
</p><p>
We should forbid such silliness by constraining the "finds an overload via ADL" cases for
customization points to only trigger with argument expressions of class or enumeration type. Note
that WG21 made a similar change to <tt>ranges::swap</tt> shortly before merging it into the working
draft to forbid users customizing behavior for pointers to program-defined types or arrays of
program-defined types.
</p>

<p><i>[2019-11-16 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after seven positive votes on the reflector.</p>


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

<blockquote class="note"><p>
[<i>Drafting note:</i> <a href="lwg-active.html#3247">3247</a> touches the same wording in
23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a>; if both are resolved simultaneously the changes should be
reconciled before passing them on to the Editor.]
</p></blockquote>

<ol>
<li><p>Modify 23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a> as follows:</p>

<blockquote><p>
(1.1) &mdash; <tt>iter_move(E)</tt>, if <del>that expression is valid,</del> <ins><tt>E</tt> has
class or enumeration type and <tt>iter_move(E)</tt> is a well-formed expression</ins> with overload
resolution performed in a context that does not include a declaration of <tt>ranges::iter_move</tt>.
</p></blockquote>
</li>

<li><p>Modify 23.3.3.2 <a href="https://wg21.link/iterator.cust.swap">[iterator.cust.swap]</a> as follows:</p>

<blockquote><p>
(4.1) &mdash; <tt>(void)iter_swap(E1, E2)</tt>, if <del>that expression is valid,</del> <ins>either
<tt>E1</tt> or <tt>E2</tt> has class or enumeration type and <tt>iter_swap(E1, E2)</tt> is a
well-formed expression</ins> with overload resolution performed in a context that includes the
declaration
<blockquote><pre>
template&lt;class I1, class I2&gt;
void iter_swap(I1, I2) = delete;
</pre></blockquote>
and does not include a declaration of <tt>ranges::iter_swap</tt>. If the function selected by
overload resolution does not exchange the values denoted by <tt>E1</tt> and <tt>E2</tt>, the program
is ill-formed with no diagnostic required.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="3300" href="#3300">3300</a><sup><a href="https://cplusplus.github.io/LWG/issue3300">(i)</a></sup>. Non-array <tt>ssize</tt> overload is underconstrained</h3>
<p><b>Section:</b> 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-09-27 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.range">active issues</a> in [iterator.range].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.range">issues</a> in [iterator.range].</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 overload of <tt>ssize</tt> specified in 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a>/18 has no constraints, 
yet it specializes <tt>make_signed_t</tt> which has a precondition that its type parameter is an 
integral type or enumeration but not <tt>bool</tt> (20.15.7.3 <a href="https://wg21.link/meta.trans.sign">[meta.trans.sign]</a>). This 
precondition needs to be propagated to <tt>ssize</tt> as "<i>Mandates</i> [or <i>Constraints</i>]: 
<tt>decltype(c.size())</tt> [meets the requirements for the type argument to <tt>make_signed</tt>]". 
"<i>Mandates</i>" seems to be more in line with LWG guidance since there are no traits nor concepts 
that observe <tt>ssize</tt>.
</p>

<p><i>[2019-11-16 Issue Prioritization]</i></p>

<p>Priority to 3 after reflector discussion.</p>

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

<ol>
<li><p>Modify 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class C&gt; constexpr auto ssize(const C&amp; c)
  -&gt; common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>decltype(c.size())</tt> is a (possibly <i>cv</i>-qualified) integral or 
enumeration type but not a <tt>bool</tt> type.</ins>
<p/>
-18- <i>Returns:</i>
<blockquote>
<pre>
static_cast&lt;common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;&gt;(c.size())
</pre>
</blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol></blockquote>

<p><i>[2019-10-28; Tim provides improved wording]</i></p>


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

<ol>
<li><p>Modify 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class C&gt; constexpr auto ssize(const C&amp; c)
  -&gt; common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>decltype(c.size())</tt> is an integral or enumeration type
other than <tt>bool</tt>.</ins>
<p/>
-18- <i>Returns:</i>
<blockquote>
<pre>
static_cast&lt;common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;&gt;(c.size())
</pre>
</blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2019-11-18; Casey comments and improves wording]</i></p>

<p>
It would be better to provided the <i>Mandates:</i> guarantee in [tab:meta.trans.sign] instead of
one special place where the <tt>make_signed</tt> template is used. The wording below attempts to 
realize that.
</p>

<p><i>[2019-11-23 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready after five positive votes on the reflector.</p>


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

<ol>
<li><p>Change Table 52 &mdash; "Sign modifications" in  [tab:meta.trans.sign] as indicated:</p>

<table border="1">
<caption>Table 52 &mdash; Sign modifications [tab:meta.trans.sign]</caption>
<tr>
<th>Template</th>
<th>Comments</th>
</tr> 

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct make_signed;</tt>
</td>
<td>
If <tt>T</tt> names a (possibly <i>cv</i>-qualified) signed integer type (6.8.1 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>) then<br/>
the member typedef <tt>type</tt> names the type <tt>T</tt>; otherwise, if <tt>T</tt> names a<br/>
(possibly <i>cv</i>-qualified) unsigned integer type then <tt>type</tt> names the<br/>
corresponding signed integer type, with the same <i>cv</i>-qualifiers as <tt>T</tt>;<br/>
otherwise, <tt>type</tt> names the signed integer type with smallest<br/>
rank (6.8.4 <a href="https://wg21.link/conv.rank">[conv.rank]</a>) for which <tt>sizeof(T) == sizeof(type)</tt>, with the same<br/>
<i>cv</i>-qualifiers as <tt>T</tt>.<br/>
<i><del>Requires</del><ins>Mandates</ins>:</i> <tt>T</tt> <del>shall be</del><ins>is</ins> a<ins>n</ins> <del>(possibly <i>cv</i>-qualified)</del> integral <del>type</del> or enumeration <ins>type other than <i>cv</i></ins> <del>but not a</del> <tt>bool</tt> <del>type</del>.
</td>
</tr>

<tr>
<td>
<tt>template &lt;class T&gt;<br/>
struct make_unsigned;</tt>
</td>
<td>
If <tt>T</tt> names a (possibly <i>cv</i>-qualified) unsigned integer type (6.8.1 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>) then<br/>
the member typedef <tt>type</tt> names the type <tt>T</tt>; otherwise, if <tt>T</tt> names a<br/>
(possibly <i>cv</i>-qualified) signed integer type then <tt>type</tt> names the<br/>
corresponding unsigned integer type, with the same <i>cv</i>-qualifiers as <tt>T</tt>;<br/>
otherwise, <tt>type</tt> names the unsigned integer type with smallest<br/>
rank (6.8.4 <a href="https://wg21.link/conv.rank">[conv.rank]</a>) for which <tt>sizeof(T) == sizeof(type)</tt>, with the same<br/>
<i>cv</i>-qualifiers as <tt>T</tt>.<br/>
<i><del>Requires</del><ins>Mandates</ins>:</i> <tt>T</tt> <del>shall be</del><ins>is</ins> a<ins>n</ins> <del>(possibly <i>cv</i>-qualified)</del> integral <del>type</del> or enumeration <ins>type other than <i>cv</i></ins> <del>but not a</del> <tt>bool</tt> <del>type</del>.
</td>
</tr>
</table>

</li>

<li><p>Change 23.7 <a href="https://wg21.link/iterator.range">[iterator.range]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class C&gt; constexpr auto ssize(const C&amp; c)
  -&gt; common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;;
</pre>
<blockquote>
<p>
-18- <i><del>Returns</del><ins>Effects</ins>:</i> <ins>Equivalent to:</ins>
<blockquote>
<pre>
<ins>return</ins> static_cast&lt;common_type_t&lt;ptrdiff_t, make_signed_t&lt;decltype(c.size())&gt;&gt;&gt;(c.size())<ins>;</ins>
</pre>
</blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3302" href="#3302">3302</a><sup><a href="https://cplusplus.github.io/LWG/issue3302">(i)</a></sup>. Range adaptor objects <tt>keys</tt> and <tt>values</tt> are unspecified</h3>
<p><b>Section:</b> 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Michel Morin <b>Opened:</b> 2019-10-04 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#ranges.syn">active issues</a> in [ranges.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#ranges.syn">issues</a> in [ranges.syn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue was submitted as editorial issue 
<a href="https://github.com/cplusplus/draft/issues/3231">cplusplus/draft#3231</a> but had been
classified as non-editorial.
<p/>
<tt>keys</tt> and <tt>values</tt> are listed in 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>, but not specified.
It seems that <a href="http://wg21.link/p1035r7">P1035R7</a> forgot to specify them (as 
<tt>elements&lt;0&gt;</tt> and <tt>elements&lt;1&gt;</tt>).
</p>

<p><i>[2019-10-31 Issue Prioritization]</i></p>

<p>Priority to 1 after reflector discussion.</p>
<p><i>[2019-11 Wednesday night issue processing in Belfast.]</i></p>

<p>Status to Ready.</p>


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

<ol>
<li><p>Modify 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>, header <tt>&lt;ranges&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  [&hellip;]
  
  template&lt;class R&gt;
    using keys_view = elements_view&lt;all_view&lt;R&gt;, 0&gt;;
  template&lt;class R&gt;
    using values_view = elements_view&lt;all_view&lt;R&gt;, 1&gt;;
  namespace views {
    template&lt;size_t N&gt;
      inline constexpr <i>unspecified</i> elements = <i>unspecified</i>;
    inline constexpr <ins>auto</ins><del><i>unspecified</i></del> keys = <ins>elements&lt;0&gt;</ins><del><i>unspecified</i></del>;
    inline constexpr <ins>auto</ins><del><i>unspecified</i></del> values = <ins>elements&lt;1&gt;</ins><del><i>unspecified</i></del>;
  }  
}
[&hellip;]
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3303" href="#3303">3303</a><sup><a href="https://cplusplus.github.io/LWG/issue3303">(i)</a></sup>. Bad "<tt>constexpr</tt>" marker for <tt>destroy/destroy_n</tt></h3>
<p><b>Section:</b> 20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2019-10-10 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
This issue was submitted as editorial issue 
<a href="https://github.com/cplusplus/draft/issues/3181">cplusplus/draft#3181</a> but is 
considered non-editorial.
<p/>
<a href="http://wg21.link/p0784r7">P0784R7</a>, approved in Cologne, added "<tt>constexpr</tt>" markers to
the overloads of <tt>destroy</tt> and <tt>destroy_n</tt> taking an <tt>ExecutionPolicy</tt> 
parameter.  This seems to be in error; parallel algorithms should not be marked "<tt>constexpr</tt>".
(None of the parallel algorithms in <tt>&lt;algorithm&gt;</tt> is marked "<tt>constexpr</tt>".)
</p>
<p><i>[2019-11 Marked as 'Ready' during Monday issue prioritization in Belfast]</i></p>



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

<ol>
<li><p>Modify 20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a>, header <tt>&lt;memory&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  
  <i>// 20.10.11.9 <a href="https://wg21.link/specialized.destroy">[specialized.destroy]</a>, destroy</i>
  template&lt;class T&gt;
    constexpr void destroy_at(T* location);
  template&lt;class ForwardIterator&gt;
    constexpr void destroy(ForwardIterator first, ForwardIterator last);
  template&lt;class ExecutionPolicy, class ForwardIterator&gt;
    <del>constexpr</del> void destroy(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                           ForwardIterator first, ForwardIterator last);
  template&lt;class ForwardIterator, class Size&gt;
    constexpr ForwardIterator destroy_n(ForwardIterator first, Size n);
  template&lt;class ExecutionPolicy, class ForwardIterator, class Size&gt;
    <del>constexpr</del> ForwardIterator destroy_n(ExecutionPolicy&amp;&amp; exec, <i>// see 25.3.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a></i>
                                        ForwardIterator first, Size n);  
  [&hellip;]
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3304" href="#3304">3304</a><sup><a href="https://cplusplus.github.io/LWG/issue3304">(i)</a></sup>. Allocate functions of <tt>std::polymorphic_allocator</tt> should require <tt>[[nodiscard]]</tt></h3>
<p><b>Section:</b> 20.12.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hiroaki Ando <b>Opened:</b> 2019-10-16 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#mem.poly.allocator.class">active issues</a> in [mem.poly.allocator.class].</p>
<p><b>View all other</b> <a href="lwg-index.html#mem.poly.allocator.class">issues</a> in [mem.poly.allocator.class].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>[[nodiscard]]</tt> is specified for <tt>std::polymorphic_allocator&lt;&gt;::allocate()</tt>.
<p/>
But the allocate functions added with <a href="https://wg21.link/p0339r6">P0339R6</a> doesn't have it.
<p/>
Isn't <tt>[[nodiscard]]</tt> necessary for these functions?
</p>

<p><i>[2019-11 Priority to 3 during Monday issue prioritization in Belfast]</i></p>

<p><i>[2019-11 After discussion with LEWG, assigning to LEWG]</i></p>

<p><i>[2019-11-4; Daniel comments]</i></p>

<p>
This issue is related to LWG <a href="lwg-closed.html#3312">3312</a>.
</p>
<p><i>[2019-11; Friday AM in Belfast. Status changed to "Ready"]</i></p>



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

<ol>
<li><p>Modify 20.12.3 <a href="https://wg21.link/mem.poly.allocator.class">[mem.poly.allocator.class]</a>, class template <tt>polymorphic_allocator</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::pmr {
  template&lt;class Tp = byte&gt; class polymorphic_allocator {
    [&hellip;]
    <i>// 20.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a>, member functions</i>
    [[nodiscard]] Tp* allocate(size_t n);
    void deallocate(Tp* p, size_t n);

    <ins>[[nodiscard]]</ins> void* allocate_bytes(size_t nbytes, size_t alignment = alignof(max_align_t));
    void deallocate_bytes(void* p, size_t nbytes, size_t alignment = alignof(max_align_t));
    template&lt;class T&gt; <ins>[[nodiscard]]</ins> T* allocate_object(size_t n = 1);
    template&lt;class T&gt; void deallocate_object(T* p, size_t n = 1);
    template&lt;class T, class... CtorArgs&gt; <ins>[[nodiscard]]</ins> T* new_object(CtorArgs&amp;&amp;... ctor_args);
    template&lt;class T&gt; void delete_object(T* p);  
    [&hellip;]
  };  
}
</pre>
</blockquote>
</li>

<li><p>Modify 20.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
<ins>[[nodiscard]]</ins> void* allocate_bytes(size_t nbytes, size_t alignment = alignof(max_align_t));
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return memory_rsrc-&gt;allocate(nbytes, alignment);</tt>
<p/>
[&hellip;]
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class T&gt;
  <ins>[[nodiscard]]</ins> T* allocate_object(size_t n = 1);
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Allocates memory suitable for holding an array of <tt>n</tt> objects of type <tt>T</tt>, as follows:
<ol style="list-style-type: none">
<li><p>(8.1) &mdash; if <tt>SIZE_MAX / sizeof(T) &lt; n</tt>, throws <tt>length_error</tt>,</p></li>
<li><p>(8.2) &mdash; otherwise equivalent to:</p>
<blockquote><pre>
return static_cast&lt;T*&gt;(allocate_bytes(n*sizeof(T), alignof(T)));
</pre></blockquote>
</li>
</ol>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class T, class CtorArgs...&gt;
  <ins>[[nodiscard]]</ins> T* new_object(CtorArgs&amp;&amp;... ctor_args);
</pre>
<blockquote>
<p>
-11- <i>Effects:</i> Allocates and constructs an object of type <tt>T</tt>, as follows.
Equivalent to:
<blockquote><pre>
T* p = allocate_object&lt;T&gt;();
try {
  construct(p, std::forward&lt;CtorArgs&gt;(ctor_args)...);
} catch (...) {
  deallocate_object(p);
  throw;
}
return p;
</pre></blockquote>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3307" href="#3307">3307</a><sup><a href="https://cplusplus.github.io/LWG/issue3307">(i)</a></sup>. <tt>std::allocator&lt;void&gt;().allocate(n)</tt></h3>
<p><b>Section:</b> 20.10.10 <a href="https://wg21.link/default.allocator">[default.allocator]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-10-25 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#default.allocator">active issues</a> in [default.allocator].</p>
<p><b>View all other</b> <a href="lwg-index.html#default.allocator">issues</a> in [default.allocator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In C++20 the <tt>std::allocator&lt;void&gt;</tt> explicit specialization is gone, which means it uses the 
primary template, which has allocate and deallocate members.
<p/>
Although it's implied by the use of <tt>sizeof(T)</tt>, <tt>std::allocator&lt;T&gt;::allocate</tt> 
doesn't have an explicit precondition that the value type is complete.
</p>

<p><i>[2019-11 Status to 'Ready' in Monday issue prioritization in Belfast]</i></p>



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

<ol>
<li><p>Modify 20.10.10.1 <a href="https://wg21.link/allocator.members">[allocator.members]</a> as indicated:</p>

<blockquote>
<pre>
[[nodiscard]] constexpr T* allocate(size_t n);
</pre>
<p>
<ins>-?- <i>Mandates:</i> <tt>T</tt> is not an incomplete type (6.8 <a href="https://wg21.link/basic.types">[basic.types]</a>).</ins>
<p/>
-2- <i>Returns:</i> A pointer to the initial element of an array of storage of size 
<tt>n * sizeof(T)</tt>, aligned appropriately for objects of type <tt>T</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3310" href="#3310">3310</a><sup><a href="https://cplusplus.github.io/LWG/issue3310">(i)</a></sup>. Replace <tt>SIZE_MAX</tt> with <tt>numeric_limits&lt;size_t&gt;::max()</tt></h3>
<p><b>Section:</b> 20.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Japan <b>Opened:</b> 2019-11-04 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#mem.poly.allocator.mem">active issues</a> in [mem.poly.allocator.mem].</p>
<p><b>View all other</b> <a href="lwg-index.html#mem.poly.allocator.mem">issues</a> in [mem.poly.allocator.mem].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses JP 218/219</b></p>

<p>
It's better to use a C++ property than C standard library macro, <tt>SIZE_MAX</tt>.
</p>

<p><i>[2019-11 Status to Ready during Tuesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 20.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> as indicated:</p>

<blockquote>
<pre>
[[nodiscard]] Tp* allocate(size_t n);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> If <tt><del>SIZE_MAX</del><ins>numeric_limits&lt;size_t&gt;::max()</ins> / sizeof(Tp) &lt; n</tt>, 
throws <tt>length_error</tt>. [&hellip;]
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class T&gt;
  T* allocate_object(size_t n = 1);
</pre>
<blockquote>
<p>
-8- <i>Effects:</i> Allocates memory suitable for holding an array of <tt>n</tt> objects of type <tt>T</tt>, as follows:
<ol style="list-style-type: none">
<li><p>(8.1) &mdash; if <tt><del>SIZE_MAX</del><ins>numeric_limits&lt;size_t&gt;::max()</ins> / sizeof(T) &lt; n</tt>, throws <tt>length_error</tt>,</p></li>
<li><p>(8.2) &mdash; otherwise equivalent to:</p>
<blockquote><pre>
return static_cast&lt;T*&gt;(allocate_bytes(n*sizeof(T), alignof(T)));
</pre></blockquote>
</li>
</ol>

</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3313" href="#3313">3313</a><sup><a href="https://cplusplus.github.io/LWG/issue3313">(i)</a></sup>. <tt>join_view::iterator::operator--</tt> is incorrectly constrained</h3>
<p><b>Section:</b> 24.7.10.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-04 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.join.iterator">active issues</a> in [range.join.iterator].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.join.iterator">issues</a> in [range.join.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 294</b></p>

<p>
<tt>join_view::iterator::operator--</tt> is improperly constrained. In the <i>Effects:</i> clause in
paragraph 14, we see the statement:
</p>
<blockquote><pre>
inner_ = ranges::end(*--outer_);
</pre></blockquote>
<p>
However, this only well-formed when <tt>end</tt> returns an iterator, not a sentinel. This
requirement is not reflected in the constraints of the function(s).
<p/>
<b>Eric Niebler:</b>
<p/>
From the WD, <tt>join_view::iterator::operator--</tt> is specified as:
</p>
<blockquote><pre>
constexpr iterator&amp; operator--()
  requires ref_is_glvalue &amp;&amp; bidirectional_range&lt;Base&gt; &amp;&amp;
    bidirectional_range&lt;range_reference_t&lt;Base&gt;&gt;;
</pre>
-14- <i>Effects:</i> Equivalent to:
<blockquote><pre>
if (outer_ == ranges::end(parent_-&gt;base_))
  inner_ = ranges::end(*--outer_);
while (inner_ == ranges::begin(*outer_))
  inner_ = ranges::end(*--outer_);
--inner_;
return *this;
</pre></blockquote>
</blockquote>
<p>
The trouble is from the lines that do:
</p>
<blockquote><pre>
  inner_ = ranges::end(*--outer_);
</pre></blockquote>
<p>
Clearly this will only compile when <tt>*--outer</tt> returns a <tt>common_range</tt>, but 
nowhere is that requirement stated.
</p>

<p><i>[2019-11 Status to Ready during Tuesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.7.10.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a>, class template <tt>join_view::iterator</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
constexpr iterator&amp; operator--()
  requires ref_is_glvalue &amp;&amp; bidirectional_range&lt;Base&gt; &amp;&amp;
           bidirectional_range&lt;range_reference_t&lt;Base&gt;&gt; <ins>&amp;&amp;
           common_range&lt;range_reference_t&lt;Base&gt;&gt;</ins>;

constexpr iterator operator--(int)
  requires ref_is_glvalue &amp;&amp; bidirectional_range&lt;Base&gt; &amp;&amp;
           bidirectional_range&lt;range_reference_t&lt;Base&gt;&gt; <ins>&amp;&amp;
           common_range&lt;range_reference_t&lt;Base&gt;&gt;</ins>;
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.10.3 <a href="https://wg21.link/range.join.iterator">[range.join.iterator]</a> as indicated:</p>

<blockquote>
<pre>
constexpr iterator&amp; operator--()
  requires ref_is_glvalue &amp;&amp; bidirectional_range&lt;Base&gt; &amp;&amp;
           bidirectional_range&lt;range_reference_t&lt;Base&gt;&gt; <ins>&amp;&amp;
           common_range&lt;range_reference_t&lt;Base&gt;&gt;</ins>;
</pre>
<blockquote>
<p>
-14- <i>Effects:</i> Equivalent to:
<blockquote><pre>
if (outer_ == ranges::end(parent_-&gt;base_))
  inner_ = ranges::end(*--outer_);
while (inner_ == ranges::begin(*outer_))
  inner_ = ranges::end(*--outer_);
--inner_;
return *this;
</pre></blockquote>
</p>
</blockquote>
<pre>
constexpr iterator operator--(int)
  requires ref_is_glvalue &amp;&amp; bidirectional_range&lt;Base&gt; &amp;&amp;
           bidirectional_range&lt;range_reference_t&lt;Base&gt;&gt; <ins>&amp;&amp;
           common_range&lt;range_reference_t&lt;Base&gt;&gt;</ins>;
</pre>
<blockquote>
<p>
-15- <i>Effects:</i> Equivalent to:
<blockquote><pre>
auto tmp = *this;
--*this;
return tmp;
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3315" href="#3315">3315</a><sup><a href="https://cplusplus.github.io/LWG/issue3315">(i)</a></sup>. Correct Allocator Default Behavior</h3>
<p><b>Section:</b> 16.5.3.5 <a href="https://wg21.link/allocator.requirements">[allocator.requirements]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-04 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.requirements">active issues</a> in [allocator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.requirements">issues</a> in [allocator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses US 162/US 163</b></p>

<p>
<b><a href="https://github.com/cplusplus/nbballot/issues/160">US 162</a>:</b>
<p/>
The default behavior for <tt>a.destroy</tt> is now to call <tt>destroy_at</tt>
<p/>
Proposed change:
<p/>
Replace "default" entry with: <tt>destroy_at(c)</tt>
</p>
<p>
<b><a href="https://github.com/cplusplus/nbballot/issues/161">US 163</a>:</b>
<p/>
The default behavior for <tt>a.construct</tt> is now to call <tt>construct_at</tt>
<p/>
Proposed change:
<p/>
Replace "default" entry with: <tt>construct_at(c, std::forward&lt;Args&gt;(args)...)</tt>
<p/>
<b>Dietmar K&uuml;hl:</b>
<p/>
In Table 34 [tab:cpp17.allocator] the behavior of <tt>a.construct(c, args)</tt> and
<tt>a.destroy(c)</tt> are described to have a default behavior of 
<tt>::new ((void*)c) C(forward&lt;Args&gt;(args))</tt> and <tt>c-&gt;~C()</tt>, respectively.
However, this table doesn't actually define what is happening if these operations are omitted: 
The behavior is provided when using an allocator is used via <tt>std::allocator_traits</tt> 
and is, thus, defined by the corresponding <tt>std::allocator_traits</tt> functions. These
functions are specified in 20.10.9.2 <a href="https://wg21.link/allocator.traits.members">[allocator.traits.members]</a> paragraphs 5 and 6 to call 
<tt>construct_at(c, std::forward&lt;Args&gt;(args)</tt> and <tt>destroy_at(p)</tt>, respectively.  
The text in the table should be updated to match the actual behavior.
</p>

<p><i>[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 16.5.3.5 <a href="https://wg21.link/allocator.requirements">[allocator.requirements]</a>, Table [tab:cpp17.allocator] 
"<tt><i>Cpp17Allocator</i></tt> requirements" as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 34 &mdash; <tt><i>Cpp17Allocator</i></tt> requirements [tab:cpp17.allocator]</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
<th>Default</th>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

<tr>
<td>
<tt>a.construct(c, args)</tt>
</td>
<td>
(not used)
</td>
<td>
<i>Effects:</i> Constructs an object of type <tt>C</tt> at <tt>c</tt>
</td>
<td>
<tt><del>::new ((void*)c) C(</del><ins>construct_at(c, std::</ins>forward&lt;Args&gt;(args)...)</tt>
</td>
</tr>

<tr>
<td>
<tt>a.destroy(c)</tt>
</td>
<td>
(not used)
</td>
<td>
<i>Effects:</i> Destroys the object at <tt>c</tt>
</td>
<td>
<tt><del>c-&gt;~C()</del><ins>destroy_at(c)</ins></tt>
</td>
</tr>

<tr>
<td colspan="4" align="center">
<tt>&hellip;</tt>
</td>
</tr>

</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3316" href="#3316">3316</a><sup><a href="https://cplusplus.github.io/LWG/issue3316">(i)</a></sup>. Correctly define epoch for <tt>utc_clock</tt> / <tt>utc_timepoint</tt></h3>
<p><b>Section:</b> 27.7.2.1 <a href="https://wg21.link/time.clock.utc.overview">[time.clock.utc.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-05 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/329">GB 333</a></b></p>

<p>
UTC epoch is not correctly defined UTC has an officially recorded epoch of 1/1/1972 00:00:00 
and is 10 seconds behind TAI.
This can be confirmed through reference to the 
<a href="https://www.bipm.org/cc/CCTF/Allowed/18/CCTF_09-32_noteUTC.pdf#page=6">BIPM</a> (the 
body that oversees international metrology)
</p>
<blockquote><p>
"The defining epoch of 1 January 1972, <tt>0 h 0m 0 s</tt> UTC was set 10 s behind TAI, which
was the approximate accumulated difference between TAI and UT1 since the inception of
TAI in 1958, and a unique fraction of a second adjustment was applied so that UTC would
differ from TAI by an integral number of seconds. The recommended maximum departure of 
UTC from UT1 was 0.7 s. The term "leap second" was introduced for the stepped second."
</p></blockquote>
<p>
Proposed change:
<p/>
<tt>utc_clock</tt> and <tt>utc_timepoint</tt> should correctly report relative to the official 
UTC epoch. 27.2.2.1 footnote 1 should read: 
</p>
<blockquote><p>
In contrast to <tt>sys_time</tt>, which does not take leap seconds into account, 
<tt>utc_clock</tt> and its associated <tt>time_point</tt>, <tt>utc_time</tt>, count time,
including leap seconds, since 1972-01-01 00:00:00 UTC. [<i>Example:</i> 
<tt>clock_cast&lt;utc_clock&gt;(sys_seconds{sys_days{1972y/January/1}}).time_since_epoch()</tt> 
is <tt>0s</tt>. <tt>clock_cast&lt;utc_clock&gt;(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()</tt>
is <tt>883'612'822</tt>, which is <tt>10'197 * 86'400s + 22s</tt>. &mdash; <i>end example</i>]
</p></blockquote>
<p>
<b>Howard Hinnant:</b>
<p/>
Clarify that the epoch of <code>utc_clock</code> is intended to be <tt>1970-01-01</tt>.
<p/>
Rationale: The main use case of <code>utc_clock</code> is to get the correct number of seconds 
when subtracting time points straddling a leap second insertion point, and this computation 
is independent of the epoch. Furthermore learning/teaching that <code>utc_clock</code> is 
<code>system_clock</code> except that <code>utc_clock</code> includes leap seconds is easier.  
And this fact is more easily understood when comparing the underlying <code>.time_since_epoch()</code> 
of equivalent time points from each clock.
</p>

<p><i>[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 27.7.2.1 <a href="https://wg21.link/time.clock.utc.overview">[time.clock.utc.overview]</a> as indicated:</p>

<blockquote>
<p>
-1- In contrast to <tt>sys_time</tt>, which does not take leap seconds into account, <tt>utc_clock</tt> 
and its associated <tt>time_point</tt>, <tt>utc_time</tt>, count time, including leap seconds, since 
1970-01-01 00:00:00 UTC. <ins>[<i>Note:</i> The UTC time standard began on 
1972-01-01 00:00:10 TAI. To measure time since this epoch instead, one can add/subtract the 
constant <tt>sys_days{1972y/1/1} - sys_days{1970y/1/1}</tt> (<tt>63'072'000s</tt>) from the 
<tt>utc_time</tt> &mdash; <i>end note</i>]</ins> [<i>Example:</i> <tt>clock_cast&lt;utc_clock&gt;(sys_seconds{sys_days{1970y/January/1}}).time_since_epoch()</tt> is <tt>0s</tt>. 
<tt>clock_cast&lt;utc_clock&gt;(sys_seconds{sys_days{2000y/January/1}}).time_since_epoch()</tt>
is <tt>946'684'822s</tt>, which is <tt>10'957 * 86'400s + 22s</tt>. &mdash; <i>end example</i>]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3317" href="#3317">3317</a><sup><a href="https://cplusplus.github.io/LWG/issue3317">(i)</a></sup>. Incorrect <tt>operator&lt;&lt;</tt> for floating-point durations</h3>
<p><b>Section:</b> 27.5.10 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-05 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.duration.io">active issues</a> in [time.duration.io].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.io">issues</a> in [time.duration.io].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/330">US 334</a></b></p>

<p>
<tt>operator&lt;&lt;</tt> for floating-point durations always produces output with six digits 
after the decimal point, and doesn't use the stream's locale either.
</p>
<p>
Proposed change:
<p/>
Rewrite the specification to not rely on <tt>to_string()</tt> for floating-point formatting.
</p>

<p><i>[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 27.5.10 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Rep, class Period>
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const duration&lt;Rep, Period&gt;&amp; d);
</pre>
<blockquote>
<p>
<del>-1- <i>Requires:</i> <tt>Rep</tt> is an integral type whose integer conversion rank 
(6.8.4 <a href="https://wg21.link/conv.rank">[conv.rank]</a>) is greater than or equal to that of <tt>short</tt>, or a floating-point type. 
<tt>charT</tt> is <tt>char</tt> or <tt>wchar_t</tt>.</del>
<p/>
-2- <i>Effects:</i> <del>Forms a <tt>basic_string&lt;charT, traits&gt;</tt> from <tt>d.count()</tt> using 
<tt>to_string</tt> if <tt>charT</tt> is <tt>char</tt>, or <tt>to_wstring</tt> if <tt>charT</tt> is 
<tt>wchar_t</tt>. Appends the units suffix described below to the <tt>basic_string</tt>.
Inserts the resulting <tt>basic_string</tt> into <tt>os</tt>. [<i>Note:</i> This specification ensures 
that the result of this streaming operation will obey the width and alignment properties of the stream. 
&mdash; <i>end note</i>]</del><ins>Inserts the duration <tt>d</tt> onto the stream <tt>os</tt> as if it 
were implemented as follows:</ins>
<blockquote><pre>
<ins>basic_ostringstream&lt;charT, traits&gt; s;
s.flags(os.flags());
s.imbue(os.getloc());
s.precision(os.precision());
s &lt;&lt; d.count() &lt;&lt; <i>units_suffix</i>;
return os &lt;&lt; s.str();</ins>
</pre></blockquote>
<p/>
-3- <del>The units suffix</del><ins><tt><i>units_suffix</i></tt></ins> depends on the type 
<tt>Period::type</tt> as follows:
<ol style="list-style-type: none">
<li><p>(3.1) &mdash; If <tt>Period::type</tt> is <tt>atto</tt>, <del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> 
is <tt>"as"</tt>.</p></li>
<li><p>(3.2) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>femto</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"fs"</tt>.</p></li>
<li><p>(3.3) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>pico</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"ps"</tt>.</p></li>
<li><p>(3.4) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>nano</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"ns"</tt>.</p></li>
<li><p>(3.5) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"&micro;s"</tt> 
(<tt>"\u00b5\u0073"</tt>).</p></li>
<li><p>(3.6) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>milli</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"ms"</tt>.</p></li>
<li><p>(3.7) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>centi</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"cs"</tt>.</p></li>
<li><p>(3.8) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>deci</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"ds"</tt>.</p></li>
<li><p>(3.9) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>ratio&lt;1&gt;</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"s"</tt>.</p></li>
<li><p>(3.10) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>deca</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"das"</tt>.</p></li>
<li><p>(3.11) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>hecto</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"hs"</tt>.</p></li>
<li><p>(3.12) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>kilo</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"ks"</tt>.</p></li>
<li><p>(3.13) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>mega</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"Ms"</tt>.</p></li>
<li><p>(3.14) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>giga</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"Gs"</tt>.</p></li>
<li><p>(3.15) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>tera</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"Ts"</tt>.</p></li>
<li><p>(3.16) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>peta</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"Ps"</tt>.</p></li>
<li><p>(3.17) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>exa</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"Es"</tt>.</p></li>
<li><p>(3.18) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>ratio&lt;60&gt;</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"min"</tt>.</p></li>
<li><p>(3.19) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>ratio&lt;3600&gt;</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"h"</tt>.</p></li>
<li><p>(3.20) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>ratio&lt;86400&gt;</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"d"</tt>.</p></li>
<li><p>(3.21) &mdash; Otherwise, if <tt>Period::type::den == 1</tt>, 
<del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> is <tt>"<i>[num</i>]s"</tt>.</p></li>
<li><p>(3.22) &mdash; Otherwise, <del>the suffix</del><ins><tt><i>units_suffix</i></tt></ins> 
is <tt>"[<i>num</i>/<i>den</i>]s"</tt>.</p></li>
</ol>
<p/>
In the list above the use of <tt><i>num</i></tt> and <tt><i>den</i></tt> refer to the static data members 
of <tt>Period::type</tt>, which are converted to arrays of <tt>charT</tt> using a decimal conversion with 
no leading zeroes.
<p/>
-4- If <tt>Period::type</tt> is <tt>micro</tt>, but the character U+00B5 cannot be represented in the 
encoding used for <tt>charT</tt>, <del>the unit suffix</del><ins><tt><i>units_suffix</i></tt></ins> 
<tt>"us"</tt> is used instead of <tt>"&micro;s"</tt>.
<p/>
-5- <i>Returns:</i> <tt>os</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3318" href="#3318">3318</a><sup><a href="https://cplusplus.github.io/LWG/issue3318">(i)</a></sup>. Clarify whether clocks can represent time before their epoch</h3>
<p><b>Section:</b> 27.7.1.1 <a href="https://wg21.link/time.clock.system.overview">[time.clock.system.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-05 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/331">GB 335</a></b></p>

<p>
Wording for clocks should be unified unless they are intended to behave differently
In 27.7.1.1 note 1 for <tt>system_clock</tt> it is stated: 
</p>
<blockquote><p>
"Objects of type <tt>system_clock</tt> represent wall clock time from the system-wide realtime
clock. Objects of type <tt>sys_time&lt;Duration&gt;</tt> measure time since (and before) 
1970-01-01 00:00:00 UTC" 
</p></blockquote>
<p>
The express statement of "since (and before)" is important given the time epoch of these clocks. 
If all the clocks support time prior to their zero-time then this should be stated explicitly. 
If not then likewise that should be noted. No change is proposed yet, clarification
required over the intended behaviour when using values prior to a given clock's epoch is
needed before the appropriate change can be suggested.
<p/>
Proposed change:
<p/>
Unify the wording.
</p>
<p>
<b>Howard Hinnant:</b>
<p/>
The clocks that are specified to have a signed <code>rep</code> imply that they will support 
negative time points, but not <i>how</i> negative. For example if <code>system_clock::duration</code> 
is <code>nanoseconds</code> represented with 64 bits, then <code>system_clock::time_point</code> 
can't possibly represent dates prior to 1677-09-21 00:12:43.145224192. This is a negative 
<code>time_point</code> since it is prior to 1970-01-01 00:00:00. But it is not very negative 
compared to (for example) <code>sys_time&lt;microseconds&gt;::min()</code>.
<p/>
Those clocks with a signed <code>rep</code> are:
</p>
<ul>
<li><p><code>system_clock</code></p></li>
<li><p><code>utc_clock</code></p></li>
<li><p><code>tai_clock</code></p></li>
<li><p><code>gps_clock</code></p></li>
<li><p><code>file_clock</code></p></li>
</ul>
<p>
Those clocks where the signed-ness of <code>rep</code> is unspecified are:
</p>
<ul>
<li><p><code>steady_clock</code></p></li>
<li><p><code>high_resolution_clock</code></p></li>
</ul>
<p>
Therefore this response emphasizes the "Unify the wording" part of this NB comment.
</p>

<p><i>[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 27.7.1.1 <a href="https://wg21.link/time.clock.system.overview">[time.clock.system.overview]</a> as indicated:</p>

<blockquote>
<p>
-1- Objects of type <tt>system_clock</tt> represent wall clock time from the system-wide 
realtime clock. Objects of type <tt>sys_time&lt;Duration&gt;</tt> measure time since 
<del>(and before)</del> 1970-01-01 00:00:00 UTC excluding leap seconds. This measure is commonly 
referred to as Unix time. This measure facilitates an efficient mapping between
<tt>sys_time</tt> and calendar types (27.8 <a href="https://wg21.link/time.cal">[time.cal]</a>). [<i>Example:</i>
<tt>sys_seconds{sys_days{1970y/January/1}}.time_since_epoch()</tt> is <tt>0s</tt>.
<tt>sys_seconds{sys_days{2000y/January/1}}.time_since_epoch()</tt> is <tt>946'684'800s</tt>, 
which is <tt>10'957 * 86'400s</tt>. &mdash; <i>end example</i>]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3319" href="#3319">3319</a><sup><a href="https://cplusplus.github.io/LWG/issue3319">(i)</a></sup>. Properly reference specification of IANA time zone database</h3>
<p><b>Section:</b> 27.11.1 <a href="https://wg21.link/time.zone.general">[time.zone.general]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Germany <b>Opened:</b> 2019-11-05 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/340">DE 344</a></b></p>

<p>
This paragraph says 
</p>
<blockquote><p>
"27.11 describes an interface for accessing the IANA Time Zone database described in RFC 6557, &hellip;"
</p></blockquote>
<p>
However, RFC 6557 does not describe the database itself; it only describes the maintenance procedures 
for that database, as its title implies (quoted in clause 2).
<p/>
Proposed change:
<p/>
Add a reference to a specification of the database itself, or excise all references to the IANA
time zone database.
</p>
<p>
<b>Howard Hinnant:</b>
<p/>
We can not entirely remove the reference to IANA because we need portable <code>time_zone</code> 
names (e.g. "America/New_York") and definitions. However the NB comment is quite accurate and 
fixed with the proposed resolution.
</p>

<p><i>[2019-11 Status to Ready during Wednesday morning issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 2 <a href="https://wg21.link/intro.refs">[intro.refs]</a> as indicated:</p>

<blockquote>
<p>
-1- The following documents are referred to in the text in such a way that some or all of their 
content constitutes requirements of this document. For dated references, only the edition cited 
applies. For undated references, the latest edition of the referenced document (including any 
amendments) applies.
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p><del>(1.2) &mdash; INTERNET ENGINEERING TASK FORCE (IETF). RFC 6557: Procedures for Maintaining 
the Time Zone Database [online]. Edited by E. Lear, P. Eggert. February 2012 [viewed 2018-03-26]. 
Available at https://www.ietf.org/rfc/rfc6557.txt</del></p></li>
<li><p>[&hellip;]</p></li>
</ol>
</p>
</blockquote>
</li>

<li><p>Modify 27.11.1 <a href="https://wg21.link/time.zone.general">[time.zone.general]</a> as indicated:</p>

<blockquote>
<p>
-1- 27.11 <a href="https://wg21.link/time.zone">[time.zone]</a> describes an interface for accessing the IANA Time Zone 
<del>d</del><ins>D</ins>atabase <del>described in RFC 6557,</del> that interoperates with 
<tt>sys_time</tt> and <tt>local_time</tt>. This interface provides time zone support to 
both the civil calendar types (27.8 <a href="https://wg21.link/time.cal">[time.cal]</a>) and to user-defined calendars. 
</p>
</blockquote>
</li>

<li><p>Modify section "Bibliography" as indicated:</p>

<blockquote>
<p>
The following documents are cited informatively in this document.
<ol style="list-style-type: none">
<li><p><ins>&mdash; IANA Time Zone Database. Available at 
<a href="https://www.iana.org/time-zones">https://www.iana.org/time-zones</a></ins></p></li>
<li><p>&mdash; ISO/IEC 10967-1:2012, <i>Information technology &mdash; Language independent arithmetic &mdash; 
Part 1: Integer and floating point arithmetic</i></p></li>
<li><p>[&hellip;]</p></li>
</ol>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3320" href="#3320">3320</a><sup><a href="https://cplusplus.github.io/LWG/issue3320">(i)</a></sup>. <tt>span::cbegin/cend</tt> methods produce different results than <tt>std::[ranges::]cbegin/cend</tt></h3>
<p><b>Section:</b> 22.7.3.7 <a href="https://wg21.link/span.iterators">[span.iterators]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Poland <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/243">PL 247</a></b></p>

<p>
<tt>span&lt;T&gt;</tt> provides a <tt>const</tt>-qualified <tt>begin()</tt> method and <tt>cbegin()</tt> 
method that produces a different result if <tt>T</tt> is not <tt>const</tt>-qualifed:
</p>
<ol>
<li><p><tt>begin()</tt> produces mutable iterator over <tt>T</tt> (as if <tt>T*</tt>)</p></li>
<li><p><tt>cbegin()</tt> produces <tt>const</tt> iterator over <tt>T</tt> (as if <tt>T const*</tt>)</p></li>
</ol>
<p>
As consequence for the object <tt>s</tt> of type <tt>span&lt;T&gt;</tt>, the call to the 
<tt>std::cbegin(s)/std::ranges::cbegin(s)</tt> produces different result than <tt>s.cbegin()</tt>.
<p/>
Proposed change:
<p/>
Change <tt>span&lt;T&gt;</tt> members <tt>cbegin()/cend()/crbegin()/crend()/const_iterator</tt> 
to be equivalent to <tt>begin()/end()/rbegin()/rend()/iterator</tt> respectively.
</p>
<p>
<b>Tomasz Kami&nacute;ski:</b>
<p/>
Per <a href="https://github.com/cplusplus/nbballot/issues/243">LEWG discussion in Belfast</a> these 
methods and related typedefs should be removed.
</p>

<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 22.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, size_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 = size_t;
    using difference_type = ptrdiff_t;
    using pointer = element_type*;
    using const_pointer = const element_type*;
    using reference = element_type&amp;;
    using const_reference = const element_type&amp;;
    using iterator = <i>implementation-defined</i>; <i>// see 22.7.3.7 <a href="https://wg21.link/span.iterators">[span.iterators]</a></i>
    <del>using const_iterator = <i>implementation-defined</i>;</del>
    using reverse_iterator = std::reverse_iterator&lt;iterator&gt;;
    <del>using const_reverse_iterator = std::reverse_iterator&lt;const_iterator&gt;;</del>
    static constexpr index_type extent = Extent;
    
    [&hellip;]
    <i>// 22.7.3.7 <a href="https://wg21.link/span.iterators">[span.iterators]</a>, iterator support</i>
    constexpr iterator begin() const noexcept;
    constexpr iterator end() const noexcept;
    <del>constexpr const_iterator cbegin() const noexcept;
    constexpr const_iterator cend() const noexcept;</del>
    constexpr reverse_iterator rbegin() const noexcept;
    constexpr reverse_iterator rend() const noexcept;
    <del>constexpr const_reverse_iterator crbegin() const noexcept;
    constexpr const_reverse_iterator crend() const noexcept;</del>
    friend constexpr iterator begin(span s) noexcept { return s.begin(); }
    friend constexpr iterator end(span s) noexcept { return s.end(); }
    [&hellip;]
  };
[&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 22.7.3.7 <a href="https://wg21.link/span.iterators">[span.iterators]</a> as indicated:</p>

<blockquote>
<pre>
using iterator = <i>implementation-defined</i>;
<del>using const_iterator = <i>implementation-defined</i>;</del>
</pre>
<blockquote>
<p>
-1- The type<del>s</del> model<ins>s</ins> <tt>contiguous_iterator</tt> 
(23.3.4.14 <a href="https://wg21.link/iterator.concept.contiguous">[iterator.concept.contiguous]</a>), meet<ins>s</ins> the <i>Cpp17RandomAccessIterator</i> 
requirements (23.3.5.6 <a href="https://wg21.link/random.access.iterators">[random.access.iterators]</a>), and meet<ins>s</ins> the requirements for 
constexpr iterators (23.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>). All requirements on container 
iterators (22.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a>) apply to <tt>span::iterator</tt> <del>and 
<tt>span::const_iterator</tt></del> as well.
</p>
</blockquote>
[&hellip;]
<pre>
<del>constexpr const_iterator cbegin() const noexcept;</del>
</pre>
<blockquote>
<p>
<del>-6- <i>Returns:</i> A constant iterator referring to the first element in the span. If 
<tt>empty()</tt> is <tt>true</tt>, then it returns the same value as <tt>cend()</tt>.</del>
</p>
</blockquote>
<pre>
<del>constexpr const_iterator cend() const noexcept;</del>
</pre>
<blockquote>
<p>
<del>-7- <i>Returns:</i> A constant iterator which is the past-the-end value.</del>
</p>
</blockquote>
<pre>
<del>constexpr const_reverse_iterator crbegin() const noexcept;</del>
</pre>
<blockquote>
<p>
<del>-8- <i>Effects:</i> Equivalent to: <tt>return const_reverse_iterator(cend());</tt></del>
</p>
</blockquote>
<pre>
<del>constexpr const_reverse_iterator crend() const noexcept;</del>
</pre>
<blockquote>
<p>
<del>-9- <i>Effects:</i> Equivalent to: <tt>return const_reverse_iterator(cbegin());</tt></del>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3321" href="#3321">3321</a><sup><a href="https://cplusplus.github.io/LWG/issue3321">(i)</a></sup>. <tt>uninitialized_construct_using_allocator</tt> should use <tt>construct_at</tt></h3>
<p><b>Section:</b> 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.uses.construction">active issues</a> in [allocator.uses.construction].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.uses.construction">issues</a> in [allocator.uses.construction].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/210">US 213</a></b></p>

<p>
<tt>uninitialized_construct_using_allocator</tt> should use <tt>construct_at</tt> instead 
of <tt>operator new</tt>
<p/>
Proposed change:
</p>
<blockquote>
<p>
<i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return <del>::new(static_cast&lt;void*&gt;(p))</del>
<ins>construct_at(p,</ins>
<del>T(</del>make_obj_using_allocator&lt;T&gt;(alloc,
std::forward&lt;Args&gt;(args)...))<ins>)</ins>;
</pre></blockquote>
</blockquote>
<p>
<b>Tim Song:</b>
<p/>
The proposed wording in the NB comment is incorrect, because it prevents guaranteed elision.
</p>

<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 20.10.8.2 <a href="https://wg21.link/allocator.uses.construction">[allocator.uses.construction]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T, class Alloc, class... Args&gt;
  constexpr T* uninitialized_construct_using_allocator(T* p, const Alloc&amp; alloc, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
-17- <i>Effects:</i> Equivalent to:
<blockquote><pre>
return <del>::new(static_cast&lt;void*&gt;(p))
  T(make_obj_using_allocator&lt;T&gt;(</del><ins>apply([&amp;](auto&amp;&amp;...xs) {
         return construct_at(p, std::forward&lt;decltype(xs)&gt;(xs)...);
     }, uses_allocator_construction_args&lt;T&gt;(</ins>alloc, std::forward&lt;Args&gt;(args)...));
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3323" href="#3323">3323</a><sup><a href="https://cplusplus.github.io/LWG/issue3323">(i)</a></sup>. <tt><i>has-tuple-element</i></tt> helper concept needs <tt>convertible_to</tt></h3>
<p><b>Section:</b> 24.7.15.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/295">GB 299</a></b></p>

<p>
<tt><i>has-tuple-element</i></tt> helper concept needs <tt>convertible_to</tt>
<p/>
The exposition-only <tt><i>has-tuple-element</i></tt> concept (for <tt>elements_view</tt>) is defined as
</p>
<blockquote><pre>
template&lt;class T, size_t N&gt;
concept <i>has-tuple-element</i> = <i>exposition only</i>
  requires(T t) {
    typename tuple_size&lt;T&gt;::type;
    requires N &lt; tuple_size_v&lt;T&gt;;
    typename tuple_element_t&lt;N, T&gt;;
    { get&lt;N&gt;(t) } -&gt; const tuple_element_t&lt;N, T&gt;&amp;;
  };
</pre></blockquote>
<p>
However, the return type constraint for <tt>{ get&lt;N&gt;(t) }</tt> is no longer valid 
under the latest concepts changes
<p/>
Proposed change:
</p>
<p>
Change to:
</p>
<blockquote><pre>
template&lt;class T, size_t N&gt;
concept <i>has-tuple-element</i> = <i>exposition only</i>
  requires(T t) {
    typename tuple_size&lt;T&gt;::type;
    requires N &lt; tuple_size_v&lt;T&gt;;
    typename tuple_element_t&lt;N, T&gt;;
    { get&lt;N&gt;(t) } -&gt; convertible_to&lt;const tuple_element_t&lt;N, T&gt;&amp;&gt;;
  };
</pre></blockquote>
<p>
<b>Jonathan Wakely:</b>
<p/>
The NB comment says "The return type constraint for <tt>{ get(t) }</tt> is no longer valid under 
the latest concepts changes." The changes referred to are those in <a href="https://wg21.link/p1452r2">P1452R2</a>. 
</p>

<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.7.15.2 <a href="https://wg21.link/range.elements.view">[range.elements.view]</a>, class template <tt>elements_view</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class T, size_t N&gt;
  concept <i>has-tuple-element</i> = <i>// exposition only</i>
    requires(T t) {
      typename tuple_size&lt;T&gt;::type;
      requires N &lt; tuple_size_v&lt;T&gt;;
      typename tuple_element_t&lt;N, T&gt;;
      { get&lt;N&gt;(t) } -&gt; <ins>convertible_to&lt;</ins>const tuple_element_t&lt;N, T&gt;&amp;<ins>&gt;</ins>;
    };
[&hellip;]
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3324" href="#3324">3324</a><sup><a href="https://cplusplus.github.io/LWG/issue3324">(i)</a></sup>. Special-case <tt>std::strong/weak/partial_order</tt> for pointers</h3>
<p><b>Section:</b> 17.11.7 <a href="https://wg21.link/cmp.alg">[cmp.alg]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Canada <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/176">CA 178</a></b></p>

<p>
<tt>std::strong_order</tt>, <tt>weak_order</tt>, and <tt>partial_order</tt> have special cases 
for floating point, but are missing special casing for pointers. <tt>compare_three_way</tt> and 
<tt>std::less</tt> have the special casing for pointers.
</p>
Proposed change:
<p/>
Change [cmp.alg] bullet 1.4 from
<br/>
"Otherwise, <tt>strong_ordering(E &lt;=&gt; F)</tt> if it is a well-formed expression."
<br/>
to
<br/>
"Otherwise, <tt>strong_ordering(compare_three_way()(E, F))</tt> if it is a well-formed expression."
<p/>
Change [cmp.alg] bullet 2.4 from
<br/>
"Otherwise, <tt>weak_ordering(E &lt;=&gt; F)</tt> if it is a well-formed expression."
<br/>
to
<br/>
"Otherwise, <tt>weak_ordering(compare_three_way()(E, F))</tt> if it is a well-formed expression."
<br/>
Change [cmp.alg] bullet 3.3 from
<br/>
"Otherwise, <tt>partial_ordering(E &lt;=&gt; F)</tt> if it is a well-formed expression."
<br/>
to
<br/>
"Otherwise, <tt>partial_ordering(compare_three_way()(E, F))</tt> if it is a well-formed expression."
<p>
<b>Dietmar K&uuml;hl:</b>
<p/>
Use <tt>compare_three_way</tt> instead of <tt>&lt;=&gt;</tt> for the various comparison algorithms.
</p>

<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Change 17.11.7 <a href="https://wg21.link/cmp.alg">[cmp.alg]</a> as indicated:</p>

<blockquote>
<p>
-1- The name <tt>strong_order</tt> [&hellip;]
</p>
<blockquote>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(1.4) &mdash; Otherwise, <tt>strong_ordering(<del>E &lt;=&gt; F</del><ins>compare_three_way()(E, F)</ins>)</tt> 
if it is a well-formed expression.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
<p>
-2- The name <tt>weak_order</tt> [&hellip;]
</p>
<blockquote>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(2.4) &mdash; Otherwise, <tt>weak_ordering(<del>E &lt;=&gt; F</del><ins>compare_three_way()(E, F)</ins>)</tt> 
if it is a well-formed expression.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
<p>
-3- The name <tt>partial_order</tt> [&hellip;]
</p>
<blockquote>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(3.3) &mdash; Otherwise, <tt>partial_ordering(<del>E &lt;=&gt; F</del><ins>compare_three_way()(E, F)</ins>)</tt> 
if it is a well-formed expression.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3325" href="#3325">3325</a><sup><a href="https://cplusplus.github.io/LWG/issue3325">(i)</a></sup>. Constrain return type of transformation function for <tt>transform_view</tt></h3>
<p><b>Section:</b> 24.7.5.2 <a href="https://wg21.link/range.transform.view">[range.transform.view]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/299">US 303</a></b></p>

<p>
The <tt>transform_view</tt> does not constrain the return type of the transformation function. It
is invalid to pass a <tt>void</tt>-returning transformation function to the <tt>transform_view</tt>, 
which would cause its <tt>iterator</tt>s' <tt>operator*</tt> member to return <tt>void</tt>.
<p/>
Proposed change:
</p>
<p>
Change the constraints on <tt>transform_view</tt> to the following:
</p>
<blockquote><pre>
template&lt;input_range V, copy_constructible F&gt;
  requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
           regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; &amp;&amp;
           <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;
class transform_view;
</pre></blockquote>
<p>
<b>Jonathan Wakely:</b>
<p/>
The NB comment says "The <tt>transform_view</tt> does not constrain the return type of the transformation 
function. It is invalid to pass a <tt>void</tt>-returning transformation function to the <tt>transform_view</tt>, 
which would cause its <tt>iterator</tt>s' <tt>operator*</tt> member to return <tt>void</tt>."
</p>

<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.7.5.2 <a href="https://wg21.link/range.transform.view">[range.transform.view]</a>, class template <tt>elements_view</tt> synopsis, 
as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;input_range V, copy_constructible F&gt;
    requires view&lt;V&gt; &amp;&amp; is_object_v&lt;F&gt; &amp;&amp;
             regular_invocable&lt;F&amp;, range_reference_t&lt;V&gt;&gt; <ins>&amp;&amp;
             <i>can-reference</i>&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;V&gt;&gt;&gt;</ins>
  class transform_view : public view_interface&lt;transform_view&lt;V, F&gt;&gt; {
    [&hellip;]
  };
[&hellip;]
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3326" href="#3326">3326</a><sup><a href="https://cplusplus.github.io/LWG/issue3326">(i)</a></sup>. <tt>enable_view</tt> has false positives</h3>
<p><b>Section:</b> 24.4.4 <a href="https://wg21.link/range.view">[range.view]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Germany <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/278">DE 282</a></b></p>

<p>
"Since the difference between range and view is largely semantic, the
two are differentiated with the help of <tt>enable_view</tt>." (&sect;3)
<p/>
<tt>enable_view</tt> is designed as on opt-in trait to specify that a type is a
view. It defaults to true for types derived from <tt>view_base</tt> (&sect;4.2) which
is clearly a form of opt-in. But it also employs a heuristic assuming that anything with 
<tt>iterator == const_iterator</tt> is also view (&sect;4.3).
<p/>
This is a very poor heuristic, the same paragraph already needs to define six
exceptions from this rule for standard library types (&sect;4.2).
<p/>
Experience in working with range-v3 has revealed multiple of our own library types as being 
affected from needing to opt-out from the "auto-opt-in", as well. This is counter-intuitive: 
something that was never designed to be a view shouldn't go through hoops so that it isn't
treated as a view.
<p/>
Proposed change:
</p>
<p>
Make <tt>enable_view</tt> truly be opt-in by relying only on explicit specialisation or 
inheritance from <tt>view_base</tt>. This means removing 24.4.4 &sect;4.2 - &sect;4.4 and 
introducing new &sect;4.2 "Otherwise, false".
<p/>
Double-check if existing standard library types like <tt>basic_string_view</tt> and <tt>span</tt> 
need to opt-in to being a view now.
</p>
<p>
<b>Casey Carter:</b>
<p/>
<tt>enable_view</tt> (24.4.4 <a href="https://wg21.link/range.view">[range.view]</a>) is designed as on opt-in trait to specify that a type 
is a view. It defaults to <tt>true</tt> for types derived from <tt>view_base</tt> &mdash; which is a 
form of opt-in &mdash; and it also employs a heuristic. Unfortunately, the heuristic has false positives. 
The working draft itself includes six exceptions to the heuristic for standard library types. Since 
false positives are much more problematic for users than false negatives, we should eliminate the heuristic.
</p>
<p><i>[2019-11 Status to Ready during Wednesday night issue processing in Belfast.]</i></p>



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

<ol>
<li><p>Modify 24.4.4 <a href="https://wg21.link/range.view">[range.view]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  inline constexpr bool enable_view = <del><i>see below</i></del><ins>derived_from&lt;T, view_base&gt;</ins>;
</pre>
<blockquote>
<p>
<del>-4- <i>Remarks:</i> For a type <tt>T</tt>, the default value of <tt>enable_view&lt;T&gt;</tt> is:</del>
<ol style="list-style-type: none">
<li><p><del>(4.1) &mdash; If <tt>derived_from&lt;T, view_base&gt;</tt> is <tt>true</tt>, 
<tt>true</tt>.</del></p></li>
<li><p><del>(4.2) &mdash; Otherwise, if <tt>T</tt> is a specialization of class template 
<tt>initializer_list</tt> (17.10 <a href="https://wg21.link/support.initlist">[support.initlist]</a>), <tt>set</tt> (22.4.6 <a href="https://wg21.link/set">[set]</a>),
<tt>multiset</tt> (22.4.7 <a href="https://wg21.link/multiset">[multiset]</a>), <tt>unordered_set</tt> (22.5.6 <a href="https://wg21.link/unord.set">[unord.set]</a>), 
<tt>unordered_multiset</tt> (22.5.7 <a href="https://wg21.link/unord.multiset">[unord.multiset]</a>), or <tt>match_results</tt>
(30.10 <a href="https://wg21.link/re.results">[re.results]</a>), <tt>false</tt>.</del></p></li>
<li><p><del>(4.3) &mdash; Otherwise, if both <tt>T</tt> and <tt>const T</tt> model <tt>range</tt> and 
<tt>range_reference_t&lt;T&gt;</tt> is not the same type as <tt>range_reference_t&lt;const T&gt;</tt>, 
<tt>false</tt>. [<i>Note:</i> Deep <tt>const</tt>-ness implies element ownership, whereas shallow const-ness 
implies reference semantics. &mdash; <i>end note</i>]</del></p></li>
<li><p><del>(4.4) &mdash; Otherwise, true.</del></p></li>
</ol>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 21.4.1 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a>, header <tt>&lt;string_view&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  <i>// 21.4.2 <a href="https://wg21.link/string.view.template">[string.view.template]</a>, class template basic_string_view</i>
  template&lt;class charT, class traits = char_traits&lt;charT&gt;&gt;
  class basic_string_view;
  
  <ins>template&lt;class charT, class traits&gt;
    inline constexpr bool ranges::enable_view&lt;basic_string_view&lt;charT, traits&gt;&gt; = true;</ins>
    
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 22.7.2 <a href="https://wg21.link/span.syn">[span.syn]</a>, header <tt>&lt;apsn&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  <i>// constants</i>
  inline constexpr size_t dynamic_extent = numeric_limits&lt;size_t&gt;::max();
  
  <i>// 22.7.3 <a href="https://wg21.link/views.span">[views.span]</a>, class template span</i>
  template&lt;class ElementType, size_t Extent = dynamic_extent&gt;
  class span;
    
  <ins>template&lt;class ElementType, size_t Extent&gt;
    inline constexpr bool ranges::enable_view&lt;span&lt;ElementType, Extent&gt;&gt; = Extent == 0 || 
      Extent == dynamic_extent;</ins>
    
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.11.4 <a href="https://wg21.link/range.split.outer.value">[range.split.outer.value]</a>, class <tt>split_view::outer_iterator::value_type</tt>
synopsis, as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The following applies the proposed wording for LWG <a href="lwg-defects.html#3276">3276</a>]
</p>
</blockquote>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class V, class Pattern&gt;
  template&lt;bool Const&gt;
  struct split_view&lt;V, Pattern&gt;::outer_iterator&lt;Const&gt;::value_type 
    <ins>: view_interface&lt;value_type&gt;</ins> {
  private:
    outer_iterator i_ = outer_iterator(); <i>// exposition only</i>
  public:
    value_type() = default;
    constexpr explicit value_type(outer_iterator i);

    constexpr inner_iterator&lt;Const&gt; begin() const;
    constexpr default_sentinel_t end() const;
  };
}
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3327" href="#3327">3327</a><sup><a href="https://cplusplus.github.io/LWG/issue3327">(i)</a></sup>. Format alignment specifiers vs. text direction</h3>
<p><b>Section:</b> 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-07 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#format.string.std">active issues</a> in [format.string.std].</p>
<p><b>View all other</b> <a href="lwg-index.html#format.string.std">issues</a> in [format.string.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/222">GB 225</a></b></p>

<p>
<tt>std::format()</tt> alignment specifiers should be independent of text direction
The align specifiers for formatting standard integer and string types are expressed in
terms of "left" and "right". However, "left alignment" as currently defined in the 
<tt>format()</tt> specification might end up being right-aligned when the resulting 
string is displayed in a RTL or bidirectional locale. This ambiguity can be resolved 
by removing "left" and "right" and replacing with "start" and "end", without changing 
any existing implementation and without changing the intent of the feature.
<p/>
Proposed change:
</p>
<p>
In [tab:format.align]:
Forces the field to be <del>left-aligned within</del> <ins>aligned to the start of</ins>
the available space and Forces the field to be <del>right-aligned within</del> 
<ins>aligned to the end of</ins> the available space
</p>
<p>
<b>Jeff Garland:</b>
<p/>
<a href="http://wiki.edg.com/bin/view/Wg21belfast/LWGWednesdayIssuePrioritization">Wiki notes 
from Belfast Wed</a>:
</p>
<blockquote><p>
# GB225
<p/>
JG: SG16 approved this.
<p/>
JG: If you scroll back up, you'll see see it's very tiny. Two line change.
<p/>
JG: I'm willing to submit an LWG issue to suggest we make a wording change to take it off our plate.
<p/>
CC: Is this the one that changes left/right to beginning/end?
<p/>
Some people: yes
<p/>
MC: Any problem with Jeff's proposed direction and this proposed fix?
<p/>
MC: I hear none. 
</p></blockquote>

<p><i>[2019-11 Moved to Ready on Friday AM in Belfast]</i></p>



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

<ol>
<li><p>Modify "Table 57 &mdash; Meaning of <i>align</i> options"
 [tab:format.align] as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 57 &mdash; Meaning of <i>align</i> options  [tab:format.align]</caption>
<tr style="text-align:center">
<th>Option</th>
<th>Meaning</th>
</tr>
<tr>
<td><tt>&lt;</tt></td>
<td>Forces the field to be <del>left-aligned within</del><ins>aligned to the start of</ins> the 
available space. This is the default for non-arithmetic types, <tt>charT</tt>, and <tt>bool</tt>, 
unless an integer presentation type is specified.</td>
</tr>
<tr>
<td><tt>&gt;</tt></td>
<td>Forces the field to be <del>right-aligned within</del><ins>aligned to the end of</ins> the 
available space. This is the default for arithmetic types other than <tt>charT</tt> and <tt>bool</tt> 
or when an integer presentation type is specified.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>
</li>

</ol>





<hr>
<h3><a name="3329" href="#3329">3329</a><sup><a href="https://cplusplus.github.io/LWG/issue3329">(i)</a></sup>. <tt>totally_ordered_with</tt> both directly and indirectly requires <tt>common_reference_with</tt></h3>
<p><b>Section:</b> 18.5.4 <a href="https://wg21.link/concept.totallyordered">[concept.totallyordered]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-07 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#concept.totallyordered">active issues</a> in [concept.totallyordered].</p>
<p><b>View all other</b> <a href="lwg-index.html#concept.totallyordered">issues</a> in [concept.totallyordered].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/199">US 201</a></b></p>

<p>
The <tt>totally_ordered_with&lt;T, U&gt;</tt> redundantly requires both
<tt>common_reference_with&lt;const remove_reference_t&amp;, const
remove_reference_t&amp;&gt;</tt> and <tt>equality_comparable_with&lt;T,
U&gt;</tt> (which also has the <tt>common_reference_with</tt> requirement). The
redundant requirement should be removed.
<p/>
Proposed change:
<p/>
Change the definition of <tt>totally_ordered_with</tt> to:
</p>
<blockquote>
<pre>
template&lt;class T, class U&gt;
  concept totally_ordered_with =
    totally_ordered&lt;T&gt; &amp;&amp; totally_ordered&lt;U&gt; &amp;&amp;
    equality_comparable_with&lt;T, U&gt; &amp;&amp;
    totally_ordered&lt;
      common_reference_t&lt;
        const remove_reference_t&lt;T&gt;&amp;,
        const remove_reference_t&lt;U&lt;&amp;&gt;&gt; &amp;&amp;
    requires(const remove_reference_t&lt;T&lt;&amp; t,
                    const remove_reference_t&gt;U&gt;&amp; u) {
      [&hellip; as before &hellip;]
</pre>
</blockquote>

<p><i>[2019-11 Moved to Ready on Friday AM in Belfast]</i></p>



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

<ol>
<li><p>Change 18.5.4 <a href="https://wg21.link/concept.totallyordered">[concept.totallyordered]</a> as indicated:</p>

<blockquote>
<p>
For some type <tt>T</tt>, let <tt>a</tt>, <tt>b</tt>, and <tt>c</tt> be lvalues
of type <tt>const remove_reference_t&lt;T&gt;</tt>. <tt>T</tt> models
<tt>totally_ordered</tt> only if
</p>
<ol style="list-style-type: none">
  <li><p>(1.1) &mdash; Exactly one of <tt>bool(a &lt; b)</tt>, <tt>bool(a &gt; b)</tt>, or <tt>bool(a == b)</tt> is
  <tt>true</tt>.</p></li>
  <li><p>(1.2) &mdash; If <tt>bool(a &lt; b)</tt> and <tt>bool(b &lt; c)</tt>, then <tt>bool(a &lt; c)</tt>.</p></li>
  <li><p>(1.3) &mdash; <tt>bool(a &gt; b) == bool(b &lt; a)</tt>.</p></li>
  <li><p>(1.4) &mdash; <tt>bool(a &lt;= b) == !bool(b &lt; a)</tt>.</p></li>
  <li><p>(1.5) &mdash; <tt>bool(a &gt;= b) == !bool(a &lt; b)</tt>.</p></li>
</ol>
<pre>
template&lt;class T, class U&gt;
  concept totally_ordered_with =
    totally_ordered&lt;T&gt; &amp;&amp; totally_ordered&lt;U&gt; &amp;&amp;
    <del>common_reference_with&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt; &amp;&amp;</del>
    <ins>equality_comparable_with&lt;T, U&gt; &amp;&amp;</ins>
    totally_ordered&lt;
      common_reference_t&lt;
        const remove_reference_t&lt;T&gt;&amp;,
        const remove_reference_t&lt;U&gt;&amp;&gt;&gt; &amp;&amp;
    <del>equality_comparable_with&lt;T, U&gt; &amp;&amp;</del>
    requires(const remove_reference_t&lt;T&gt;&amp; t,
             const remove_reference_t&lt;U&gt;&amp; u) {
      { t &lt;  u } -&gt; boolean;
      { t &gt;  u } -&gt; boolean;
      { t &lt;= u } -&gt; boolean;
      { t &gt;= u } -&gt; boolean;
      { u &lt;  t } -&gt; boolean;
      { u &gt;  t } -&gt; boolean;
      { u &lt;= t } -&gt; boolean;
      { u &gt;= t } -&gt; boolean;
    };
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3330" href="#3330">3330</a><sup><a href="https://cplusplus.github.io/LWG/issue3330">(i)</a></sup>. Include <tt>&lt;compare&gt;</tt> from most library headers</h3>
<p><b>Section:</b> 17.12.1 <a href="https://wg21.link/coroutine.syn">[coroutine.syn]</a>, 19.5.1 <a href="https://wg21.link/system.error.syn">[system.error.syn]</a>, 20.2.1 <a href="https://wg21.link/utility.syn">[utility.syn]</a>, 20.5.2 <a href="https://wg21.link/tuple.syn">[tuple.syn]</a>, 20.6.2 <a href="https://wg21.link/optional.syn">[optional.syn]</a>, 20.7.2 <a href="https://wg21.link/variant.syn">[variant.syn]</a>, 20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a>, 20.17.1 <a href="https://wg21.link/type.index.synopsis">[type.index.synopsis]</a>, 21.3.1 <a href="https://wg21.link/string.syn">[string.syn]</a>, 21.4.1 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a>, 22.3.2 <a href="https://wg21.link/array.syn">[array.syn]</a>, 22.3.3 <a href="https://wg21.link/deque.syn">[deque.syn]</a>, 22.3.4 <a href="https://wg21.link/forward.list.syn">[forward.list.syn]</a>, 22.3.5 <a href="https://wg21.link/list.syn">[list.syn]</a>, 22.3.6 <a href="https://wg21.link/vector.syn">[vector.syn]</a>, 22.4.2 <a href="https://wg21.link/associative.map.syn">[associative.map.syn]</a>, 22.4.3 <a href="https://wg21.link/associative.set.syn">[associative.set.syn]</a>, 22.5.2 <a href="https://wg21.link/unord.map.syn">[unord.map.syn]</a>, 22.5.3 <a href="https://wg21.link/unord.set.syn">[unord.set.syn]</a>, 22.6.2 <a href="https://wg21.link/queue.syn">[queue.syn]</a>, 22.6.3 <a href="https://wg21.link/stack.syn">[stack.syn]</a>, 23.2 <a href="https://wg21.link/iterator.synopsis">[iterator.synopsis]</a>, 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>, 27.2 <a href="https://wg21.link/time.syn">[time.syn]</a>, 29.11.5 <a href="https://wg21.link/fs.filesystem.syn">[fs.filesystem.syn]</a>, 30.4 <a href="https://wg21.link/re.syn">[re.syn]</a>, 32.4.1 <a href="https://wg21.link/thread.syn">[thread.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> United States <b>Opened:</b> 2019-11-07 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/179">US 181</a></b></p>

<p>
The spaceship <tt>operator&lt;=&gt;</tt> is typically not usable unless the library 
header <tt>&lt;compare&gt;</tt> is directly included by the user. Many standard
library headers provide overloads for this operator. Worse, several standard classes
have replaced their existing definition for comparison operators with a reliance on the
spaceship operator, and existing code will break if the necessary header is not
(transitively) included. In a manner similar to the mandated library headers
transitively <tt>#include</tt>-ing <tt>&lt;initializer_list&gt;</tt> in C++11, 
these headers should mandate a transitive <tt>#include &lt;compare&gt;</tt>.
<p/>
Proposed change:
<p/>
Add:
<p/>
<tt>#include &lt;compare&gt;</tt>
<p/>
to the header synopsis for each of the following headers:
</p>
<blockquote>
<pre>
&lt;array&gt;
&lt;chrono&gt;
&lt;coroutine&gt;
&lt;deque&gt;
&lt;forward_list&gt;
&lt;filesystem&gt;
&lt;iterator&gt;
&lt;list&gt;
&lt;map&gt;
&lt;memory&gt;
&lt;optional&gt;
&lt;queue&gt;
&lt;ranges&gt;
&lt;regex&gt;
&lt;set&gt;
&lt;stack&gt;
&lt;string&gt;
&lt;string_view&gt;
&lt;system_error&gt;
&lt;thread&gt;
&lt;tuple&gt;
&lt;type_index&gt;
&lt;unordered_map&gt;
&lt;unordered_set&gt;
&lt;utility&gt;
&lt;variant&gt;
&lt;vector&gt;
</pre>
</blockquote>

<p><i>[2019-11 Moved to Ready on Friday AM in Belfast]</i></p>



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

<ol>
<li><p>Add</p>
<blockquote><pre>
#include &lt;compare&gt;
</pre></blockquote>
<p>
to the following header synopses:
</p>
<ol>
<li>17.12.1 <a href="https://wg21.link/coroutine.syn">[coroutine.syn]</a></li>
<li>19.5.1 <a href="https://wg21.link/system.error.syn">[system.error.syn]</a></li>
<li>20.2.1 <a href="https://wg21.link/utility.syn">[utility.syn]</a></li>
<li>20.5.2 <a href="https://wg21.link/tuple.syn">[tuple.syn]</a></li>
<li>20.6.2 <a href="https://wg21.link/optional.syn">[optional.syn]</a></li>
<li>20.7.2 <a href="https://wg21.link/variant.syn">[variant.syn]</a></li>
<li>20.10.2 <a href="https://wg21.link/memory.syn">[memory.syn]</a></li>
<li>20.17.1 <a href="https://wg21.link/type.index.synopsis">[type.index.synopsis]</a></li>
<li>21.3.1 <a href="https://wg21.link/string.syn">[string.syn]</a></li>
<li>21.4.1 <a href="https://wg21.link/string.view.synop">[string.view.synop]</a></li>
<li>22.3.2 <a href="https://wg21.link/array.syn">[array.syn]</a></li>
<li>22.3.3 <a href="https://wg21.link/deque.syn">[deque.syn]</a></li>
<li>22.3.4 <a href="https://wg21.link/forward.list.syn">[forward.list.syn]</a></li>
<li>22.3.5 <a href="https://wg21.link/list.syn">[list.syn]</a></li>
<li>22.3.6 <a href="https://wg21.link/vector.syn">[vector.syn]</a></li>
<li>22.4.2 <a href="https://wg21.link/associative.map.syn">[associative.map.syn]</a></li>
<li>22.4.3 <a href="https://wg21.link/associative.set.syn">[associative.set.syn]</a></li>
<li>22.5.2 <a href="https://wg21.link/unord.map.syn">[unord.map.syn]</a></li>
<li>22.5.3 <a href="https://wg21.link/unord.set.syn">[unord.set.syn]</a></li>
<li>22.6.2 <a href="https://wg21.link/queue.syn">[queue.syn]</a></li>
<li>22.6.3 <a href="https://wg21.link/stack.syn">[stack.syn]</a></li>
<li>23.2 <a href="https://wg21.link/iterator.synopsis">[iterator.synopsis]</a></li>
<li>24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a></li>
<li>27.2 <a href="https://wg21.link/time.syn">[time.syn]</a></li>
<li>29.11.5 <a href="https://wg21.link/fs.filesystem.syn">[fs.filesystem.syn]</a></li>
<li>30.4 <a href="https://wg21.link/re.syn">[re.syn]</a></li>
<li>32.4.1 <a href="https://wg21.link/thread.syn">[thread.syn]</a></li>
</ol>
</li>
</ol>




<hr>
<h3><a name="3331" href="#3331">3331</a><sup><a href="https://cplusplus.github.io/LWG/issue3331">(i)</a></sup>. Define <tt>totally_ordered/_with</tt> in terms of <tt><i>partially-ordered-with</i></tt></h3>
<p><b>Section:</b> 18.5.4 <a href="https://wg21.link/concept.totallyordered">[concept.totallyordered]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-08 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#concept.totallyordered">active issues</a> in [concept.totallyordered].</p>
<p><b>View all other</b> <a href="lwg-index.html#concept.totallyordered">issues</a> in [concept.totallyordered].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/200">GB 202</a></b></p>

<p>
Define <tt>totally_ordered[_with]</tt>
in terms of <tt><i>partially-ordered-with</i></tt>.
This will simplify the definition of both concepts
(particularly <tt>totally_ordered_with</tt>), and
make them in-line with <tt>equality_comparable[_with]</tt>.
Now that we've defined <tt><i>partially-ordered-with</i></tt>
for 17.11.4 <a href="https://wg21.link/cmp.concept">[cmp.concept]</a>, we should consider
utilising it in as many locations as possible.
</p><p>
Proposed change:
</p><p>
<pre>
template&lt;class T&gt;
  concept totally_ordered =
    equality_comparable&lt;T&gt; &amp;&amp;
    <i>partially-ordered-with</i>&lt;T, T&gt;;

template&lt;class T, class U&gt;
  concept totally_ordered_with =
    totally_ordered&lt;T&gt; &amp;&amp;
    totally_ordered&lt;U&gt; &amp;&amp;
    common_reference_with&lt;
      const remove_reference_t&lt;T&gt;&amp;,
      const remove_reference_t&lt;U&gt;&amp;&gt; &amp;&amp;
    totally_ordered&lt;
      common_reference_t&lt;
        const remove_reference_t&lt;T&gt;&amp;,
        const remove_reference_t&lt;U&gt;&amp;&gt;&gt; &amp;&amp;
    equality_comparable_with&lt;T, U&gt; &amp;&amp;
    <i>partially-ordered-with</i>&lt;T, U&gt;;
</pre>
</p><p>
LWG discussion in Belfast notes that <a href="lwg-active.html#3329">3329</a>
also touches the definition of <tt>totally_ordered_with</tt>;
the two sets of changes are consistent.
</p>
<p><i>[2019-11 Status to Ready Friday afternoon LWG in Belfast]</i></p>



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

<ol>
<li><p>Change 18.5.4 <a href="https://wg21.link/concept.totallyordered">[concept.totallyordered]</a> as follows:</p>
<blockquote><pre>
template&lt;class T&gt;
  concept totally_ordered =
    equality_comparable&lt;T&gt; &amp;&amp; <ins><i>partially-ordered-with</i>&lt;T, T&gt;;</ins>
    <del>requires(const remove_reference_t&lt;T&gt;&amp; a,</del>
             <del>const remove_reference_t&lt;T&gt;&amp; b) {</del>
      <del>{ a &lt;  b } -&gt; boolean;</del>
      <del>{ a &gt;  b } -&gt; boolean;</del>
      <del>{ a &lt;= b } -&gt; boolean;</del>
      <del>{ a &gt;= b } -&gt; boolean;</del>
    <del>};</del>
</pre><p>
-1- For some type <tt>T</tt>, let <tt>a</tt>, <tt>b</tt>, and <tt>c</tt>
be lvalues of type <tt>const remove_reference_t&lt;T&gt;</tt>.
<tt>T</tt> models <tt>totally_ordered</tt> only if
</p><p>
(1.1) &mdash; Exactly one of <tt>bool(a &lt; b)</tt>, <tt>bool(a &gt; b)</tt>,
or <tt>bool(a == b)</tt> is <tt>true</tt>.
</p><p>
(1.2) &mdash; If <tt>bool(a &lt; b)</tt> and <tt>bool(b &lt; c)</tt>,
then <tt>bool(a &lt; c)</tt>.
</p><p>
<del>(1.3) &mdash; <tt>bool(a &gt; b) == bool(b &lt; a)</tt>.</del>
</p><p>
(1.4) &mdash; <tt>bool(a &lt;= b) == !bool(b &lt; a)</tt>.
</p><p>
(1.5) &mdash; <tt>bool(a &gt;= b) == !bool(a &lt; b)</tt>.
</p><pre>
template&lt;class T, class U&gt;
  concept totally_ordered_with =
    totally_ordered&lt;T&gt; &amp;&amp; totally_ordered&lt;U&gt; &amp;&amp;
    common_reference_with&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt; &amp;&amp;
    totally_ordered&lt;
      common_reference_t&lt;
        const remove_reference_t&lt;T&gt;&amp;,
        const remove_reference_t&lt;U&gt;&amp;&gt;&gt; &amp;&amp;
      equality_comparable_with&lt;T, U&gt; &amp;&amp;
      <ins><i>partially-ordered-with</i>&lt;T, U&gt;;</ins>
      <del>requires(const remove_reference_t&lt;T&gt;&amp; t,</del>
               <del>const remove_reference_t&lt;U&gt;&amp; u) {</del>
        <del>{ t &lt;  u } -&gt; boolean;</del>
        <del>{ t &gt;  u } -&gt; boolean;</del>
        <del>{ t &lt;= u } -&gt; boolean;</del>
        <del>{ t &gt;= u } -&gt; boolean;</del>
        <del>{ u &lt;  t } -&gt; boolean;</del>
        <del>{ u &gt;  t } -&gt; boolean;</del>
        <del>{ u &lt;= t } -&gt; boolean;</del>
        <del>{ u &gt;= t } -&gt; boolean;</del>
      <del>};</del>
</pre><p>
[&hellip;]
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3332" href="#3332">3332</a><sup><a href="https://cplusplus.github.io/LWG/issue3332">(i)</a></sup>. Issue in &sect;[time.format]</h3>
<p><b>Section:</b> 27.12 <a href="https://wg21.link/time.format">[time.format]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Mateusz Pusz <b>Opened:</b> 2019-11-05 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.format">active issues</a> in [time.format].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.format">issues</a> in [time.format].</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>
Table 97 [tab:time.format.spec] enumerates <tt>'q'</tt> and <tt>'Q'</tt> but those are not specified in 
<i>chrono-format-spec</i> provided in paragraph 1 of sub-clause 27.12 <a href="https://wg21.link/time.format">[time.format]</a>.
</p>

<p><i>[2019-11-23 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.</p>


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

<ol>
<li><p>Change the <i>type</i> grammar element in 27.12 <a href="https://wg21.link/time.format">[time.format]</a> p1 as indicated:</p>

<blockquote>
<pre>
<i>type:</i> one of
         a A b B c C d D e F g G h H I j m M n
         p <ins>q Q</ins> r R S t T u U V w W x X y Y z Z %
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3338" href="#3338">3338</a><sup><a href="https://cplusplus.github.io/LWG/issue3338">(i)</a></sup>. Rename <tt>default_constructible</tt> to <tt>default_initializable</tt></h3>
<p><b>Section:</b> 18.4.12 <a href="https://wg21.link/concept.defaultconstructible">[concept.defaultconstructible]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-11-18 <b>Last modified:</b> 2019-12-02</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#concept.defaultconstructible">issues</a> in [concept.defaultconstructible].</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>
WG21 merged <a href="http://wg21.link/p1754r1">P1754R1</a> "Rename concepts to <tt>standard_case</tt> for C++20" 
into the working draft as LWG Motion 11 in 2019 Cologne. That proposal contains editorial instructions to 
rename what was the <tt>DefaultConstructible</tt> concept:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<pre>
IF LWG3151 ACCEPTED:
  default_initializable
ELSE
  default_constructible
</pre>
</blockquote>
<p>
Notably LWG <a href="lwg-active.html#3151">3151</a> "<tt>ConvertibleTo</tt> rejects conversions from array and function types" is 
not the intended issue number, LWG <a href="lwg-defects.html#3149">3149</a> "<tt>DefaultConstructible</tt> should require default 
initialization" is. It was made clear during discussion in LEWG that 3149 would change the concept to require default-initialization to be valid rather than value-initialization which the <tt>is_default_constructible</tt> 
trait requires. LEWG agreed that it would be confusing to have a trait and concept with very similar names 
yet slightly different meanings, and approved <a href="http://wg21.link/p1754r1">P1754R1</a>'s proposed renaming.
<p/>
LWG <a href="lwg-defects.html#3149">3149</a> was moved to "Ready" but not approved by WG21 until Belfast &mdash; after the application 
of P1754R1 to the working draft &mdash; so this renaming has not happened, but the rationale remains valid.
</p>

<p><i>[2019-11-30 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.</p>


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

<ol>
<li><p>Change the stable name "[concept.defaultconstructible]" to "[concept.default.init]" and retitle 
"Concept <tt>default_constructible</tt>" to "Concept <tt>default_initializable</tt>". Replace all references 
to the name <tt>default_constructible</tt> with <tt>default_initializable</tt> (There are 20 occurrences).</p>
</li>
</ol>




<hr>
<h3><a name="3346" href="#3346">3346</a><sup><a href="https://cplusplus.github.io/LWG/issue3346">(i)</a></sup>. <tt>pair</tt> and <tt>tuple</tt> copy and move constructor have backwards specification</h3>
<p><b>Section:</b> 20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>, 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-11-26 <b>Last modified:</b> 2019-12-09</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#pairs.pair">active issues</a> in [pairs.pair].</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</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>
20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a> p2 and 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> p3 say:
</p>
<blockquote>
<p>
The defaulted move and copy constructor, respectively, of {<tt>pair</tt>,<tt>tuple</tt>} is a constexpr 
function if and only if all required element-wise initializations for copy and move, respectively, 
would satisfy the requirements for a constexpr function.
</p>
</blockquote>
<p>
Note that we specify the copy constructor in terms of element move operations and the move constructor 
in terms of element copy operations. Is that really the intent? This appears to be how this was originally 
specified when the wording was added by <a href="https://wg21.link/n3471">N3471</a>.
</p>

<p><i>[2019-12-01; Daniel comments and provides wording]</i></p>

<p>
These inverted wording effects are an unintended oversight caused by <a href="https://wg21.link/n3471">N3471</a>.
</p>

<p><i>[2019-12-08 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after ten positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a> as indicated:</p>

<blockquote>
<p>
-2- The defaulted move and copy constructor, respectively, of <tt>pair</tt> shall be a constexpr function 
if and only if all required element-wise initializations for <del>copy</del><ins>move</ins> and 
<del>move</del><ins>copy</ins>, respectively, would satisfy the requirements for a constexpr function.
</p>
</blockquote>
</li>

<li><p>Modify 20.5.3.1 <a href="https://wg21.link/tuple.cnstr">[tuple.cnstr]</a> as indicated:</p>

<blockquote>
<p>
-3- The defaulted move and copy constructor, respectively, of <tt>tuple</tt> shall be a constexpr function 
if and only if all required element-wise initializations for <del>copy</del><ins>move</ins> and 
<del>move</del><ins>copy</ins>, respectively, would satisfy the requirements for a constexpr function. 
The defaulted move and copy constructor of <tt>tuple&lt;&gt;</tt> shall be constexpr functions.
</p>
</blockquote>
</li>


</ol>




<hr>
<h3><a name="3349" href="#3349">3349</a><sup><a href="https://cplusplus.github.io/LWG/issue3349">(i)</a></sup>. Missing <tt>__cpp_lib_constexpr_complex</tt> for P0415R1</h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2019-12-04 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#version.syn">active issues</a> in [version.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#version.syn">issues</a> in [version.syn].</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>
<a href="https://wg21.link/p1902r1">P1902R1</a> "Missing feature-test macros 2017-2019", accepted in Belfast, said:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
[<a href="https://wg21.link/p0415r1">P0415R1</a>] (Constexpr for <tt>std::complex</tt>): this paper proposes to 
introduce the macro <tt>__cpp_lib_constexpr_complex</tt>. That is, introducing a new macro for this header.
</p>
</blockquote>
<p>
However, <tt>__cpp_lib_constexpr_complex</tt> wasn't mentioned in the Wording section, and doesn't appear 
in the latest WP <a href="https://wg21.link/n4842">N4842</a>.
<p/>
<a href="https://wg21.link/p0415r1">P0415R1</a> was accepted in Albuquerque (November 2017), and the paper itself 
said "For the purposes of SG10, we recommend the feature-testing macro name <tt>__cpp_lib_constexpr_complex</tt>.", 
so this has been accepted and then overlooked by WG21 twice.
</p>

<p><i>[2019-12-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after twelve positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> p2 as indicated:</p>
<blockquote>
<pre>
[&hellip;]
#define __cpp_lib_constexpr_algorithms    201806L <i>// also in &lt;algorithm&gt;</i>
<ins>#define __cpp_lib_constexpr_complex       201711L <i>// also in &lt;complex&gt;</i></ins>
#define __cpp_lib_constexpr_dynamic_alloc 201907L <i>// also in &lt;memory&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3350" href="#3350">3350</a><sup><a href="https://cplusplus.github.io/LWG/issue3350">(i)</a></sup>. Simplify return type of <tt>lexicographical_compare_three_way</tt></h3>
<p><b>Section:</b> 25.7.11 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-12-04 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.three.way">issues</a> in [alg.three.way].</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 current return type is:
</p>
<blockquote><pre>
common_comparison_category_t&lt;decltype(comp(*b1, *b2)), strong_ordering&gt;
</pre></blockquote>
<p>
Finding the common category with <tt>strong_ordering</tt> doesn't do anything. The common category of <tt>X</tt> 
and <tt>strong_ordering</tt> is always <tt>X</tt>, so we can simplify it to:
</p>
<blockquote><pre>
common_comparison_category_t&lt;decltype(comp(*b1, *b2))&gt;
</pre></blockquote>
<p>
This can further be simplified, because the common category of any comparison category type is just that type. 
If it's not a comparison category then the result would be <tt>void</tt>, but the function would be ill-formed 
in that case anyway, as we have:
</p>
<blockquote><p>
<i>Mandates:</i> <tt>decltype(comp(*b1, *b2))</tt> is a comparison category type.
</p></blockquote>
<p>
So the only effect of the complicated return type seems to be to cause the return type to be deduced as 
<tt>void</tt> for specializations of the function template that are ill-formed if called. That doesn't seem useful.
</p>

<p><i>[2019-12-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after seven positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 25.4 <a href="https://wg21.link/algorithm.syn">[algorithm.syn]</a> as indicated:</p>
<blockquote>
<pre>
[&hellip;]
<i>// 25.7.11 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a>, three-way comparison algorithms</i>
template&lt;class InputIterator1, class InputIterator2, class Cmp&gt;
  constexpr auto
    lexicographical_compare_three_way(InputIterator1 b1, InputIterator1 e1,
                                      InputIterator2 b2, InputIterator2 e2,
                                      Cmp comp)
      -&gt; <del>common_comparison_category_t&lt;</del>decltype(comp(*b1, *b2))<del>, strong_ordering&gt;</del>;
template&lt;class InputIterator1, class InputIterator2&gt;
  constexpr auto
    lexicographical_compare_three_way(InputIterator1 b1, InputIterator1 e1,
                                      InputIterator2 b2, InputIterator2 e2);
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 25.7.11 <a href="https://wg21.link/alg.three.way">[alg.three.way]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class InputIterator1, class InputIterator2, class Cmp&gt;
  constexpr auto
    lexicographical_compare_three_way(InputIterator1 b1, InputIterator1 e1,
                                      InputIterator2 b2, InputIterator2 e2,
                                      Cmp comp)
      -&gt; <del>common_comparison_category_t&lt;</del>decltype(comp(*b1, *b2))<del>, strong_ordering&gt;</del>;
</pre>
<blockquote>
<p>
-1- <i>Mandates:</i> <tt>decltype(comp(*b1, *b2))</tt> is a comparison category type.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3351" href="#3351">3351</a><sup><a href="https://cplusplus.github.io/LWG/issue3351">(i)</a></sup>. <tt>ranges::enable_safe_range</tt> should not be constrained</h3>
<p><b>Section:</b> 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-12-05 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#ranges.syn">active issues</a> in [ranges.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#ranges.syn">issues</a> in [ranges.syn].</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>
Currently <tt>ranges::enable_safe_range</tt> is constrained with <tt>ranges::range</tt>, which not only 
forces the compiler to do unnecessary satisfaction checking when it's used, but also creates a tricky 
dependency cycle (<tt>ranges::range</tt> depends on <tt>ranges::begin</tt> which depends on 
<tt>ranges::enable_safe_range</tt> which depends on <tt>ranges::range</tt>).
<p/>
The only place the variable template is expected to be used is in the <tt>ranges::safe_range</tt> concept, 
which already checks <tt>range&lt;T&gt;</tt> before using <tt>enable_safe_range&lt;T&gt;</tt> anyway.
<p/>
The constraint serves no purpose and should be removed.
</p>

<p><i>[2019-12-12 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after eight positive votes on the reflector.</p>


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

<ol>
<li><p>Modify 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> The definition in 24.4.2 <a href="https://wg21.link/range.range">[range.range]</a> p7 is already unconstrained, 
which contradicts the synopsis.]
</p>
</blockquote>

<blockquote>
<pre>
[&hellip;]
<i>// 24.4.2 <a href="https://wg21.link/range.range">[range.range]</a>, ranges</i>
template&lt;class T&gt;
concept range = <i>see below</i>;

template&lt;<del>range</del><ins>class</ins> T&gt;
inline constexpr bool enable_safe_range = false;

template&lt;class T&gt;
concept safe_range = <i>see below</i>;
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3356" href="#3356">3356</a><sup><a href="https://cplusplus.github.io/LWG/issue3356">(i)</a></sup>. <tt>__cpp_lib_nothrow_convertible</tt> should be <tt>__cpp_lib_<em>is_</em>nothrow_convertible</tt></h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2019-12-09 <b>Last modified:</b> 2020-01-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#version.syn">active issues</a> in [version.syn].</p>
<p><b>View all other</b> <a href="lwg-index.html#version.syn">issues</a> in [version.syn].</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>
<a href="https://wg21.link/p1902r1">P1902R1</a> introduced the feature test macro 
<tt>__cpp_lib_nothrow_convertible</tt>, but every other example in SD-6 of a feature test macro 
testing for the presence of a single type trait <em>FOO</em> is named <tt>__cpp_lib_<em>FOO</em></tt>. 
This macro should be renamed <tt>__cpp_lib_is_nothrow_convertible</tt>.
<p/>
This naming convention should probably be documented in SD-6 as policy.
</p>

<p><i>[2019-12-21 Issue Prioritization]</i></p>

<p>Status to Tentatively Ready and priority to 0 after seven positive votes on the reflector.
A convincing argument was that currently no vendor had published a release with the previous
feature macro.</p>


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

<ol>
<li><p>Modify 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a>, header <tt>&lt;version&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
#define __cpp_lib_not_fn                 201603L  <i>// also in &lt;functional&gt;</i>
#define __cpp_lib_<ins>is_</ins>nothrow_convertible 201806L  <i>// also in &lt;type_traits&gt;</i>
#define __cpp_lib_null_iterators         201304L  <i>// also in &lt;iterator&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3360" href="#3360">3360</a><sup><a href="https://cplusplus.github.io/LWG/issue3360">(i)</a></sup>. <tt>three_way_comparable_with</tt> is inconsistent with similar concepts</h3>
<p><b>Section:</b> 17.11.4 <a href="https://wg21.link/cmp.concept">[cmp.concept]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-12-18 <b>Last modified:</b> 2020-01-12</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 concept <tt>three_way_comparable_with</tt> is defined in 17.11.4 <a href="https://wg21.link/cmp.concept">[cmp.concept]</a> as:
</p>
<blockquote>
<pre>
template&lt;class T, class U, class Cat = partial_ordering&gt;
  concept three_way_comparable_with =
    <i>weakly-equality-comparable-with</i>&lt;T, U&gt; &amp;&amp;
    <i>partially-ordered-with</i>&lt;T, U&gt; &amp;&amp;
    three_way_comparable&lt;T, Cat&gt; &amp;&amp;
    three_way_comparable&lt;U, Cat&gt; &amp;&amp;
    common_reference_with&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt; &amp;&amp;
    three_way_comparable&lt;
      common_reference_t&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt;, Cat&gt; &amp;&amp;
    requires(const remove_reference_t&lt;T&gt;&amp; t, const remove_reference_t&lt;U&gt;&amp; u) {
      { t &lt;=&gt; u } -&gt; <i>compares-as</i>&lt;Cat&gt;;
      { u &lt;=&gt; t } -&gt; <i>compares-as</i>&lt;Cat&gt;;
    };
</pre>
</blockquote>
<p>
Which notably doesn't follow the requirement ordering:
</p>
<ol>
<li><p>same-type requirements on <tt>T</tt></p></li>
<li><p>same-type requirements on <tt>U</tt></p></li>
<li><p><tt>common_reference_with</tt> requirement</p></li>
<li><p>same-type requirements on <tt>common_reference_t&lt;T, U&gt;</tt></p></li>
<li><p>cross-type requirements on <tt>T</tt> and <tt>U</tt></p></li>
</ol>
<p>
that the other cross-type comparison concepts (18.5.3 <a href="https://wg21.link/concept.equalitycomparable">[concept.equalitycomparable]</a>, 
18.5.4 <a href="https://wg21.link/concept.totallyordered">[concept.totallyordered]</a>) use. There were some motivating reasons for that ordering:
</p>
<ol>
<li><p>The existence of a common reference type is effectively an opt-in to cross-type concepts. 
Avoiding checking cross-type expressions when no common reference type exists can enable the 
concepts to work even in the presence of poorly-constrained "accidental" cross-type operator 
templates which could otherwise produce compile errors instead of dissatisfied concepts.</p></li>
<li><p>Putting the simpler same-type requirements first can help produce simpler error messages 
when applying the wrong concept to a pair of types, or the right concept to the wrong pair of types. 
"<tt>Frobnozzle &lt;=&gt; Frobnozzle</tt> is not a valid expression" is more easily deciphered than 
is "<tt>std::common_reference&lt;int, FrobNozzle&gt;</tt> has no member named type".</p></li>
</ol>
<p>
<tt>three_way_comparable_with</tt> should be made consistent with <tt>equality_comparable_with</tt> and 
<tt>totally_ordered_with</tt> for the above reasons and to make it easier to reason about comparison concepts 
in general.
</p>
<p><i>[01-2020 Status set to Tentatively Ready after five positive votes on the reflector.]</i></p>



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

<ol>
<li><p>Modify 17.11.4 <a href="https://wg21.link/cmp.concept">[cmp.concept]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class T, class U, class Cat = partial_ordering&gt;
  concept three_way_comparable_with =
    <del><i>weakly-equality-comparable-with</i>&lt;T, U&gt; &amp;&amp;</del>
    <del><i>partially-ordered-with</i>&lt;T, U&gt; &amp;&amp;</del>
    three_way_comparable&lt;T, Cat&gt; &amp;&amp;
    three_way_comparable&lt;U, Cat&gt; &amp;&amp;
    common_reference_with&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt; &amp;&amp;
    three_way_comparable&lt;
      common_reference_t&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt;, Cat&gt; &amp;&amp;
    <ins><i>weakly-equality-comparable-with</i>&lt;T, U&gt; &amp;&amp;</ins>
    <ins><i>partially-ordered-with</i>&lt;T, U&gt; &amp;&amp;</ins>
    requires(const remove_reference_t&lt;T&gt;&amp; t, const remove_reference_t&lt;U&gt;&amp; u) {
      { t &lt;=&gt; u } -&gt; <i>compares-as</i>&lt;Cat&gt;;
      { u &lt;=&gt; t } -&gt; <i>compares-as</i>&lt;Cat&gt;;
    };
</pre>
</blockquote>
</li>

</ol>




</body>
</html>
