<!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 Resolved Directly 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 Resolved Directly In Prague</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2117R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2020-02-14 at 16:23:28 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>Immediate Issues</h2>
<hr>
<h3><a name="1203" href="#1203">1203</a><sup><a href="https://cplusplus.github.io/LWG/issue1203">(i)</a></sup>. More useful rvalue stream insertion</h3>
<p><b>Section:</b> 29.7.5.5 <a href="https://wg21.link/ostream.rvalue">[ostream.rvalue]</a>, 29.7.4.5 <a href="https://wg21.link/istream.rvalue">[istream.rvalue]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2009-09-06 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#ostream.rvalue">issues</a> in [ostream.rvalue].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
29.7.5.5 <a href="https://wg21.link/ostream.rvalue">[ostream.rvalue]</a> was created to preserve the ability to insert
into (and extract from 29.7.4.5 <a href="https://wg21.link/istream.rvalue">[istream.rvalue]</a>) rvalue streams:
</p>

<blockquote><pre>
template &lt;class charT, class traits, class T&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
  operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os, const T&amp; x);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
</p>
<p>
2 <i>Returns:</i> <tt>os</tt>
</p>
</blockquote>
</blockquote>

<p>
This is good as it allows code that wants to (for example) open, write to, and
close an <tt>ofstream</tt> all in one statement:
</p>

<blockquote><pre>
std::ofstream("log file") &lt;&lt; "Some message\n";
</pre></blockquote>

<p>
However, I think we can easily make this "rvalue stream helper" even easier to
use.  Consider trying to quickly create a formatted string.  With the current
spec you have to write:
</p>

<blockquote><pre>
std::string s = static_cast&lt;std::ostringstream&amp;&gt;(std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
</pre></blockquote>

<p>
This will store "<tt>i = 10</tt>" (for example) in the string <tt>s</tt>.  Note
the need to cast the stream back to <tt>ostringstream&amp;</tt> prior to using
the member <tt>.str()</tt>.  This is necessary because the inserter has cast
the <tt>ostringstream</tt> down to a more generic <tt>ostream</tt> during the
insertion process.
</p>

<p>
I believe we can re-specify the rvalue-inserter so that this cast is unnecessary.
Thus our customer now has to only type:
</p>

<blockquote><pre>
std::string s = (std::ostringstream() &lt;&lt; "i = " &lt;&lt; i).str();
</pre></blockquote>

<p>
This is accomplished by having the rvalue stream inserter return an rvalue of
the same type, instead of casting it down to the base class.  This is done by
making the stream generic, and constraining it to be an rvalue of a type derived
from <tt>ios_base</tt>.
</p>

<p>
The same argument and solution also applies to the inserter.  This code has been
implemented and tested.
</p>

<p><i>[
2009 Santa Cruz:
]</i></p>

<blockquote><p>
NAD Future. No concensus for change.
</p></blockquote>

<p><i>[LEWG Kona 2017]</i></p>

<p>Recommend Open: Design looks right.</p>

<p><i>[
2018-05-25, Billy O'Neal requests this issue be reopened and provides P/R
rebased against N4750
]</i></p>


<p>Billy O'Neal requests this issue be reopened, as changing operator&gt;&gt;
and operator&lt;&lt; to use perfect forwarding as described here is necessary to
implement LWG <a href="lwg-defects.html#2534">2534</a> which was accepted. Moreover, this P/R also resolves
LWG <a href="lwg-active.html#2498">2498</a>.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
Change 29.7.4.5 <a href="https://wg21.link/istream.rvalue">[istream.rvalue]</a>:
</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Istream</ins>, class T&gt;
  <del>basic_istream&lt;charT, traits&gt;&amp;</del> <ins>Istream&amp;&amp;</ins>
  operator&gt;&gt;(<del>basic_istream&lt;charT, traits&gt;</del> <ins>Istream</ins>&amp;&amp; is, T&amp; x);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> <tt>is &gt;&gt; x</tt>
</p>
<p>
2 <i>Returns:</i> <tt><ins>std::move(</ins>is<ins>)</ins></tt>
</p>
<p><ins>
3 <i>Remarks:</i> This signature shall participate in overload resolution if
and only if <tt>Istream</tt> is not an lvalue reference type and is derived from
<tt>ios_base</tt>.
</ins></p>
</blockquote>
</blockquote>

<p>
Change 29.7.5.5 <a href="https://wg21.link/ostream.rvalue">[ostream.rvalue]</a>:
</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Ostream</ins>, class T&gt;
  <del>basic_ostream&lt;charT, traits&gt;&amp;</del> <ins>Ostream&amp;&amp;</ins>
  operator&lt;&lt;(<del>basic_ostream&lt;charT, traits&gt;</del> <ins>Ostream</ins>&amp;&amp; os, const T&amp; x);
</pre>
<blockquote>
<p>
1 <i>Effects:</i> <tt>os &lt;&lt; x</tt>
</p>
<p>
2 <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
</p>
<p><ins>
3 <i>Remarks:</i> This signature shall participate in overload resolution if
and only if <tt>Ostream</tt> is not an lvalue reference type and is derived from
<tt>ios_base</tt>.
</ins></p>
</blockquote>
</blockquote>
</blockquote>

<p><i>[2018-12-03, Ville comments]</i></p>

<p>
The implementation in libstdc++ doesn't require derivation from <tt>ios_base</tt>, it 
requires convertibility to <tt>basic_istream/basic_ostream</tt>. This has been found to be 
important to avoid regressions with existing stream wrappers.
<p/>
In libstdc++, the inserter/extractor also don't return a reference to the template parameter, 
they return a reference to the <tt>basic_istream/basic_ostream</tt> <em>specialization</em>
the template parameter converts to. This was done in order to try and be closer to the earlier 
specification's return type, which specified <tt>basic_ostream&lt;charT, traits&gt;&amp;</tt>
and <tt>basic_istream&lt;charT, traits&gt;&amp;</tt>. So we detected convertibility to
(a type convertible to) those, and returned the result of that conversion. That doesn't seem to 
be necessary, and probably bothers certain chaining cases. Based on recent experiments, it seems
that this return-type dance (as opposed to just returning what the p/r suggests) is unnecessary, 
and doesn't trigger any regressions.
</p>
<p><i>[2019-01-20 Reflector prioritization]</i></p>

<p>Set Priority to 2</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This resolution is relative to N4750.</p>
<p>
Change 29.7.4.5 <a href="https://wg21.link/istream.rvalue">[istream.rvalue]</a> as follows:
</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Istream</ins>, class T&gt;
  <del>basic_istream&lt;charT, traits&gt;&amp;</del> <ins>Istream&amp;&amp;</ins>
  operator&gt;&gt;(<del>basic_istream&lt;charT, traits&gt;</del> <ins>Istream</ins>&amp;&amp; is, T&amp;&amp; x);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to:
</p>
<pre>
<tt>is &gt;&gt; std::forward&lt;T&gt;(x)</tt>
return <ins>std::move(</ins>is<ins>)</ins>;
</pre>
<p>-2- <i>Remarks:</i> This function shall not participate in overload
resolution unless the expression <tt>is &gt;&gt; std::forward&lt;T&gt;(x)</tt> is
well-formed<ins>, <tt>Istream</tt> is not an lvalue reference type, and
<tt>Istream</tt> is derived from <tt>ios_base</tt></ins>.</p>
</blockquote>
</blockquote>

<p>
Change 29.7.5.5 <a href="https://wg21.link/ostream.rvalue">[ostream.rvalue]</a>:
</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Ostream</ins>, class T&gt;
  <del>basic_ostream&lt;charT, traits&gt;&amp;</del> <ins>Ostream&amp;&amp;</ins>
  operator&lt;&lt;(<del>basic_ostream&lt;charT, traits&gt;</del> <ins>Ostream</ins>&amp;&amp; os, const T&amp; x);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> As if by: <tt>os &lt;&lt; x;</tt>
</p>
<p>
-2- <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>
</p>
<p>
-3- <i>Remarks:</i> This signature shall not participate in overload resolution
unless the expression <tt>os &lt;&lt; x</tt> is well-formed<ins>,
<tt>Ostream</tt> is not an lvalue reference type, and <tt>Ostream</tt> is
derived from <tt>ios_base</tt></ins>.</p>
</blockquote>
</blockquote>
</blockquote>

<p><i>[2019-03-17; Daniel comments and provides updated wording]</i></p>

<p>
After discussion with Ville it turns out that the "derived from <tt>ios_base</tt>" approach works fine and
no breakages were found in regression tests. As result of that discussion the wording was rebased to the 
most recent working draft and the "overload resolution participation" wording was replaced by a 
corresponding <i>Constraints:</i> element.
</p>
<p><i>[2020-02 Status to Immediate on Friday morning in Prague.]</i></p>



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

<ol>
<li><p>Change 29.7.4.5 <a href="https://wg21.link/istream.rvalue">[istream.rvalue]</a> as follows:</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Istream</ins>, class T&gt;
  <del>basic_istream&lt;charT, traits&gt;&amp;</del> <ins>Istream&amp;&amp;</ins>
  operator&gt;&gt;(<del>basic_istream&lt;charT, traits&gt;</del> <ins>Istream</ins>&amp;&amp; is, T&amp;&amp; x);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The expression <tt>is &gt;&gt; std::forward&lt;T&gt;(x)</tt> is
well-formed and <tt>Istream</tt> is publicly and unambiguously derived from <tt>ios_base</tt>.</ins>
<p/>
-1- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
<tt>is &gt;&gt; std::forward&lt;T&gt;(x)</tt>;
return <ins>std::move(</ins>is<ins>)</ins>;
</pre></blockquote>
<p><del>-2- <i>Remarks:</i> This function shall not participate in overload resolution 
unless the expression <tt>is &gt;&gt; std::forward&lt;T&gt;(x)</tt> is well-formed.</del></p>
</blockquote>
</blockquote>
</li>

<li>
<p>
Change 29.7.5.5 <a href="https://wg21.link/ostream.rvalue">[ostream.rvalue]</a>:
</p>

<blockquote><pre>
template &lt;class <del>charT, class traits</del> <ins>Ostream</ins>, class T&gt;
  <del>basic_ostream&lt;charT, traits&gt;&amp;</del> <ins>Ostream&amp;&amp;</ins>
  operator&lt;&lt;(<del>basic_ostream&lt;charT, traits&gt;</del> <ins>Ostream</ins>&amp;&amp; os, const T&amp; x);
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The expression <tt>os &lt;&lt; x</tt> is well-formed and <tt>Ostream</tt> 
is publicly and unambiguously derived from <tt>ios_base</tt>.</ins>
<p/>
-1- <i>Effects:</i> As if by: <tt>os &lt;&lt; x;</tt>
<p/>
-2- <i>Returns:</i> <tt><ins>std::move(</ins>os<ins>)</ins></tt>.
<p/>
<del>-3- <i>Remarks:</i> This signature shall not participate in overload resolution
unless the expression <tt>os &lt;&lt; x</tt> is well-formed.</del></p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2859" href="#2859">2859</a><sup><a href="https://cplusplus.github.io/LWG/issue2859">(i)</a></sup>. Definition of <em>reachable</em> in [ptr.launder] misses pointer arithmetic from pointer-interconvertible object</h3>
<p><b>Section:</b> 17.6.4 <a href="https://wg21.link/ptr.launder">[ptr.launder]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2017-01-31 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#ptr.launder">issues</a> in [ptr.launder].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Given:
</p>
<blockquote><pre>
struct A { int x, y; };
A a[100];
</pre></blockquote>
<p>
The bytes which compose <tt>a[3]</tt> can be reached from <tt>&amp;a[2].x</tt>:
<tt>reinterpret_cast&lt;A *&gt;(&amp;a[2].x) + 1</tt> points to <tt>a[3]</tt>,
however, the definition of "reachable" in [ptr.launder] does not encompass this case.
</p>

<p><i>[2017-03-04, Kona]</i></p>

<p>Set priority to 2. Assign this (and <a href="lwg-closed.html#2860">2860</a>) to Core.</p>

<p><i>[2017-08-14, CWG telecon note]</i></p>

<p>
CWG is fine with the proposed resolution.  
</p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>




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

<ol>
<li><p>Modify 17.6.4 <a href="https://wg21.link/ptr.launder">[ptr.launder]</a> as indicated:</p>
<blockquote>
<pre>
template &lt;class T&gt; constexpr T* launder(T* p) noexcept;
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Remarks:</i> An invocation of this function may be used in a core constant expression whenever the value
of its argument may be used in a core constant expression. A byte of storage <ins><tt><i>b</i></tt></ins> is 
reachable through a pointer value that points to an object <tt><i>Y</i></tt> if <ins>there is an object 
<tt><i>Z</i></tt>, pointer-interconvertible with <tt><i>Y</i></tt>, such that <tt><i>b</i></tt></ins> <del>it</del> 
is within the storage occupied by <tt><i><ins>Z</ins><del>Y</del></i></tt>, <del>an object that is 
pointer-interconvertible with <tt><i>Y</i></tt>,</del> or the immediately-enclosing array object if 
<tt><i><ins>Z</ins><del>Y</del></i></tt> is an array element. The program is ill-formed if <tt>T</tt> is a function type or 
(possibly <i>cv</i>-qualified) <tt>void</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3018" href="#3018">3018</a><sup><a href="https://cplusplus.github.io/LWG/issue3018">(i)</a></sup>. <tt>shared_ptr</tt> of function type</h3>
<p><b>Section:</b> 20.11.3 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2017-09-13 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared">active issues</a> in [util.smartptr.shared].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared">issues</a> in [util.smartptr.shared].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>shared_ptr</tt> has been designed to support use cases where it owns a pointer to function, and whose deleter 
does something with it. This can be used, for example, to keep a dynamic library loaded for as long as their exported 
functions are referenced.
<p/>
Implementations have overlooked that the <tt>T</tt> in <tt>shared_ptr&lt;T&gt;</tt> can be a function type. It isn't 
immediately obvious from the standard, and it's not possible to tell from the wording that this is intentional.
</p>

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

<p>Priority set to 3</p>

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

<ol>
<li><p>Edit 20.11.3 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a> as indicated:</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- Specializations of <tt>shared_ptr</tt> shall be <tt>CopyConstructible</tt>, <tt>CopyAssignable</tt>, and 
<tt>LessThanComparable</tt>, allowing their use in standard containers. Specializations of <tt>shared_ptr</tt> shall be 
contextually convertible to <tt>bool</tt>, allowing their use in boolean expressions and declarations in conditions. 
<del>The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.</del>
<p/>
<ins>-?- The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type. <tt>T*</tt> shall be an object 
pointer type or a function pointer type.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13; Prague]</i></p>

<p>
LWG would prefer to make the new constraint a Mandates-like thing.
</p>

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

<ol>
<li><p>Edit 20.11.3 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a> as indicated:</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- Specializations of <tt>shared_ptr</tt> shall be <i>Cpp17CopyConstructible</i>, <i>Cpp17CopyAssignable</i>, and 
<i>Cpp17LessThanComparable</i>, allowing their use in standard containers. Specializations of <tt>shared_ptr</tt> shall be 
contextually convertible to <tt>bool</tt>, allowing their use in boolean expressions and declarations in conditions. 
<del>The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.</del>
<p/>
<ins>-?- The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type. The program is ill-formed
unless <tt>T*</tt> is an object pointer type or a function pointer type.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02 Friday AM discussion in Prague.]</i></p>

<p>Marshall provides updated wording; status to Immediate</p>


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

<ol>
<li><p>Edit 20.11.3 <a href="https://wg21.link/util.smartptr.shared">[util.smartptr.shared]</a> as indicated:</p>
<blockquote>
<p>
[&hellip;]
<p/>
-2- Specializations of <tt>shared_ptr</tt> shall be <i>Cpp17CopyConstructible</i>, <i>Cpp17CopyAssignable</i>, and 
<i>Cpp17LessThanComparable</i>, allowing their use in standard containers. Specializations of <tt>shared_ptr</tt> shall be 
contextually convertible to <tt>bool</tt>, allowing their use in boolean expressions and declarations in conditions. 
<del>The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.</del>
<p/>
<ins>-?- The template parameter <tt>T</tt> of <tt>shared_ptr</tt> may be an incomplete type.
[<i>Note:</i> T may be a function type. <i>-- end note</i>]</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3050" href="#3050">3050</a><sup><a href="https://cplusplus.github.io/LWG/issue3050">(i)</a></sup>. Conversion specification problem in <tt>chrono::duration</tt> constructor</h3>
<p><b>Section:</b> 27.5.1 <a href="https://wg21.link/time.duration.cons">[time.duration.cons]</a>, 27.5.5 <a href="https://wg21.link/time.duration.nonmember">[time.duration.nonmember]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2018-01-22 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.duration.cons">active issues</a> in [time.duration.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.cons">issues</a> in [time.duration.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The converting constructor in <tt>std::chrono::duration</tt> is currently specified as
(27.5.1 <a href="https://wg21.link/time.duration.cons">[time.duration.cons]</a> p1):
</p>
<blockquote>
<pre>
template&lt;class Rep2&gt;
  constexpr explicit duration(const Rep2&amp; r);
</pre>
<blockquote>
<p>
<i>Remarks:</i> This constructor shall not participate in overload resolution unless <tt>Rep2</tt> is
implicitly convertible to <tt>rep</tt> and [&hellip;]
</p>
</blockquote>
</blockquote>
<p>
But the parameter is of type <tt>Rep2 const</tt>, so we should check that <tt>Rep2 const</tt> is
implicitly convertible to <tt>rep</tt>, not just <tt>Rep2</tt>. This means that for a type like:
</p>
<blockquote>
<pre>
struct X { operator int64_t() /* not const */; };
</pre>
</blockquote>
<p>
<tt>std::is_constructible_v&lt;std::chrono::seconds, X&gt;</tt> is <tt>true</tt>, but actual
construction will fail to compile.
<p/>
Further analysis of sub-clause 27.5 <a href="https://wg21.link/time.duration">[time.duration]</a> revealed similar specification problems in
some other functions.
</p>

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

<p>P3; Status to Open</p>

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

<p>Jonathan to provide updated wording; the underlying text has changed.</p>

<p><i>[2018-12-05 Jonathan provides new wording]</i></p>

<p>In San Diego Geoff noticed that the current WP does not use <tt>CR</tt>.
Jonathan provides new wording consistent with the
<a href="https://github.com/cplusplus/draft/pull/1985">editorial changes</a>
that removed <tt>CR</tt>.</p>

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

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

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

<blockquote>
<pre>
template&lt;class Rep2&gt;
  constexpr explicit duration(const Rep2&amp; r);
</pre>
<blockquote>
<p>
-1- <i>Remarks:</i> This constructor shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, rep&gt;</tt> is <tt>true</tt></ins><del><tt>Rep2</tt>
is implicitly convertible to <tt>rep</tt></del> and
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>treat_as_floating_point_v&lt;rep&gt;</tt> is <tt>true</tt> or</p></li>
<li><p>(1.2) &mdash; <tt>treat_as_floating_point_v&lt;Rep2&gt;</tt> is <tt>false</tt>.</p></li>
</ol>
[&hellip;]
<p/>
-2- <i>Effects:</i> Constructs an object of type <tt>duration</tt>.
<p/>
-3- <i>Postconditions:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-4- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, CR(Rep1, Rep2)&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>CR(Rep1, Rep2)</tt></del>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Rep2, class Period&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>
<blockquote>
<p>
-6- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep1&amp;, CR(Rep1, Rep2)&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep1</tt> is implicitly convertible to <tt>CR(Rep1, Rep2)</tt></del>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-8- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, CR(Rep1, Rep2)&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>CR(Rep1, Rep2)</tt></del>
and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-11- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, CR(Rep1, Rep2)&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>CR(Rep1, Rep2)</tt></del>
and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

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

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

<blockquote>
<pre>
template&lt;class Rep2&gt;
  constexpr explicit duration(const Rep2&amp; r);
</pre>
<blockquote>
<p>
-1- <i>Remarks:</i> This constructor shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, rep&gt;</tt> is <tt>true</tt></ins><del><tt>Rep2</tt>
is implicitly convertible to <tt>rep</tt></del> and
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>treat_as_floating_point_v&lt;rep&gt;</tt> is <tt>true</tt> or</p></li>
<li><p>(1.2) &mdash; <tt>treat_as_floating_point_v&lt;Rep2&gt;</tt> is <tt>false</tt>.</p></li>
</ol>
[&hellip;]
<p/>
-2- <i>Effects:</i> Constructs an object of type <tt>duration</tt>.
<p/>
-3- <i>Postconditions:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-4- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>common_type_t&lt;Rep1, Rep2&gt;</tt></del>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Rep2, class Period&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>
<blockquote>
<p>
-6- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep1&amp;, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep1</tt> is implicitly convertible to <tt>common_type_t&lt;Rep1, Rep2&gt;</tt></del>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-8- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>common_type_t&lt;Rep1, Rep2&gt;</tt></del>
and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-11- <i>Remarks:</i> This operator shall not participate in overload resolution unless
<ins><tt>is_convertible_v&lt;const Rep2&amp;, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is
<tt>true</tt></ins><del><tt>Rep2</tt> is implicitly convertible to <tt>common_type_t&lt;Rep1, Rep2&gt;</tt></del>
and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Rebase to most recent working draft
</p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

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

<blockquote>
<pre>
template&lt;class Rep2&gt;
  constexpr explicit duration(const Rep2&amp; r);
</pre>
<blockquote>
<p>
-1- <i>Constraints:</i> <tt>is_convertible_v&lt;<ins>const</ins> Rep2<ins>&amp;</ins>, rep&gt;</tt> is <tt>true</tt> and
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>treat_as_floating_point_v&lt;rep&gt;</tt> is <tt>true</tt> or</p></li>
<li><p>(1.2) &mdash; <tt>treat_as_floating_point_v&lt;Rep2&gt;</tt> is <tt>false</tt>.</p></li>
</ol>
[&hellip;]
<p/>
-2- <i>Postconditions:</i> <tt>count() == static_cast&lt;rep&gt;(r)</tt>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-4- <i>Constraints:</i> <tt>is_convertible_v&lt;<ins>const</ins> Rep2<ins>&amp;</ins>, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is <tt>true</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Rep2, class Period&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator*(const Rep1&amp; s, const duration&lt;Rep2, Period&gt;&amp; d);
</pre>
<blockquote>
<p>
-6- <i>Constraints:</i> <tt>is_convertible_v&lt;<ins>const</ins> Rep1<ins>&amp;</ins>, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> is <tt>true</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator/(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-8- <i>Constraints:</i> <tt>is_convertible_v&lt;<ins>const</ins> Rep2<ins>&amp;</ins>, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> 
is <tt>true</tt> and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Rep1, class Period, class Rep2&gt;
  constexpr duration&lt;common_type_t&lt;Rep1, Rep2&gt;, Period&gt;
    operator%(const duration&lt;Rep1, Period&gt;&amp; d, const Rep2&amp; s);
</pre>
<blockquote>
<p>
-12- <i>Constraints:</i> <tt>is_convertible_v&lt;<ins>const</ins> Rep2<ins>&amp;</ins>, common_type_t&lt;Rep1, Rep2&gt;&gt;</tt> 
is <tt>true</tt> and <tt>Rep2</tt> is not a specialization of <tt>duration</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3141" href="#3141">3141</a><sup><a href="https://cplusplus.github.io/LWG/issue3141">(i)</a></sup>. <tt>CopyConstructible</tt> doesn't preserve source values</h3>
<p><b>Section:</b> 18.6 <a href="https://wg21.link/concepts.object">[concepts.object]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-07-07 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The design intent of the <tt>CopyConstructible</tt> concept has always been that the source of the
constructions it requires be left unmodified. Before <a href="https://wg21.link/p0541r1">P0541R1</a>
reformulated the <tt>Constructible</tt> concept in terms of <tt>is_constructible</tt>, the wording
which is now in 18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>/5:
<blockquote>
This document uses a notational convention to specify which expressions declared in a
<i>requires-expression</i> modify which inputs: except where otherwise specified, [&hellip;] Operands that
are constant lvalues or rvalues are required to not be modified.
</blockquote>
indirectly enforced that requirement. Unfortunately, <em>nothing</em> in the current wording in
18.4.14 <a href="https://wg21.link/concept.copyconstructible">[concept.copyconstructible]</a> enforces that requirement.
</p>

<p><i>[2018-11 Reflector prioritization]</i></p>

<p>Set Priority to 2</p>

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

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

<p>Change 18.4.14 <a href="https://wg21.link/concept.copyconstructible">[concept.copyconstructible]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T&gt;
  concept CopyConstructible =
    MoveConstructible&lt;T&gt; &amp;&amp;
    Constructible&lt;T, T&amp;&gt; &amp;&amp; ConvertibleTo&lt;T&amp;, T&gt; &amp;&amp;
    Constructible&lt;T, const T&amp;&gt; &amp;&amp; ConvertibleTo&lt;const T&amp;, T&gt; &amp;&amp;
    Constructible&lt;T, const T&gt; &amp;&amp; ConvertibleTo&lt;const T, T&gt;;
</pre>
<p>
-1- If <tt>T</tt> is an object type, then let <tt>v</tt> be an lvalue of type (possibly <tt>const</tt>)
<tt>T</tt> or an rvalue of type <tt>const T</tt>. <tt>CopyConstructible&lt;T&gt;</tt> is satisfied
only if
</p><p>
(1.1) &mdash; After the definition <tt>T u = v;</tt>, <tt>u</tt> is equal to <tt>v</tt> <ins>and
<tt>v</tt> is unmodified</ins>.
</p><p>
(1.2) &mdash; <tt>T(v)</tt> is equal to <tt>v</tt> <ins>and does not modify <tt>v</tt></ins>.
</p>
</blockquote>
</blockquote>

<p><i>[2020-02-13 Per LWG review, Casey provides updated P/R wording.]</i></p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

<p>Change 18.4.14 <a href="https://wg21.link/concept.copyconstructible">[concept.copyconstructible]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T&gt;
  concept copy_constructible =
    move_constructible&lt;T&gt; &amp;&amp;
    constructible_from&lt;T, T&amp;&gt; &amp;&amp; convertible_to&lt;T&amp;, T&gt; &amp;&amp;
    constructible_from&lt;T, const T&amp;&gt; &amp;&amp; convertible_to&lt;const T&amp;, T&gt; &amp;&amp;
    constructible_from&lt;T, const T&gt; &amp;&amp; convertible_to&lt;const T, T&gt;;
</pre>
<p>
-1- If <tt>T</tt> is an object type, then let <tt>v</tt> be an lvalue of type (possibly <tt>const</tt>)
<tt>T</tt> or an rvalue of type <tt>const T</tt>. <tt>T</tt> models <tt>copy_constructible</tt> only if
</p><p>
(1.1) &mdash; After the definition <tt>T u = v;</tt>, <tt>u</tt> is equal to <tt>v</tt> <ins>(18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>) and
<tt>v</tt> is not modified</ins>.
</p><p>
(1.2) &mdash; <tt>T(v)</tt> is equal to <tt>v</tt> <ins>and does not modify <tt>v</tt></ins>.
</p>
</blockquote>






<hr>
<h3><a name="3150" href="#3150">3150</a><sup><a href="https://cplusplus.github.io/LWG/issue3150">(i)</a></sup>. <tt>UniformRandomBitGenerator</tt> should validate <tt>min</tt> and <tt>max</tt></h3>
<p><b>Section:</b> 26.6.2.3 <a href="https://wg21.link/rand.req.urng">[rand.req.urng]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-08-09 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#rand.req.urng">active issues</a> in [rand.req.urng].</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.urng">issues</a> in [rand.req.urng].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
26.6.2.3 <a href="https://wg21.link/rand.req.urng">[rand.req.urng]</a>
<a href="https://wg21.link/rand.req.urng#2">paragraph 2</a> specifies axioms for
the <tt>UniformRandomBitGenerator</tt> concept:
</p>
<blockquote>
<p>
2 Let <tt>g</tt> be an object of type <tt>G</tt>. <tt>G</tt> models
<tt>UniformRandomBitGenerator</tt> only if
</p><p>
(2.1) &mdash; both <tt>G::min()</tt> and <tt>G::max()</tt> are constant
expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>),
</p><p>
(2.2) &mdash; <tt>G::min() &lt; G::max()</tt>,
</p><p>
(2.3) &mdash; <tt>G::min() &lt;= g()</tt>,
</p><p>
(2.4) &mdash; <tt>g() &lt;= G::max()</tt>, and
</p><p>
(2.5) &mdash; <tt>g()</tt> has amortized constant complexity.
</p>
</blockquote>
<p>
Bullets 2.1 and 2.2 are both compile-time requirements that ought to be
validated by the concept.
</p>

<p><i>[2018-08-20 Priority set to 3 after reflector discussion]</i></p>


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

<ol>
<li><p>Modify 26.6.2.3 <a href="https://wg21.link/rand.req.urng">[rand.req.urng]</a> as follows:</p>

<blockquote>
<p>1 A <i>uniform random bit generator</i> <tt>g</tt> of type <tt>G</tt> is a
function object returning unsigned integer values such that each value in the
range of possible results has (ideally) equal probability of being returned.
[<i>Note:</i> The degree to which <tt>g</tt>'s results approximate the ideal is
often determined statistically.&mdash;<i>end note</i>]
</p>
<blockquote>
<pre>
<ins>template&lt;auto&gt; struct <i>require-constant</i>; // <i>exposition-only</i></ins>

template&lt;class G&gt;
  concept UniformRandomBitGenerator =
    Invocable&lt;G&amp;&gt; &amp;&amp; UnsignedIntegral&lt;invoke_result_t&lt;G&amp;&gt;&gt; &amp;&amp;
    requires {
      { G::min() } -> Same&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
      { G::max() } -> Same&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
      <ins>typename <i>require-constant</i>&lt;G::min()&gt;;</ins>
      <ins>typename <i>require-constant</i>&lt;G::max()&gt;;</ins>
      <ins>requires G::min() &lt; G::max();</ins>
    };
</pre>
</blockquote>
<p>
2 Let <tt>g</tt> be an object of type <tt>G</tt>. <tt>G</tt> models
<tt>UniformRandomBitGenerator</tt> only if
</p><p>
<del>(2.1) &mdash; both <tt>G​::​min()</tt> and <tt>G​::​max()</tt> are constant
expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>),</del>
</p><p>
<del>(2.2) &mdash; <tt>G​::​min() &lt; G​::​max()</tt>,</del>
</p><p>
(2.3) &mdash; <tt>G​::​min() &lt;= g()</tt>,
</p><p>
(2.4) &mdash; <tt>g() &lt;= G​::​max()</tt>, and
</p><p>
(2.5) &mdash; <tt>g()</tt> has amortized constant complexity.
</p><p>
3 A class <tt>G</tt> meets the <i>uniform random bit generator</i> requirements
if <tt>G</tt> models <tt>UniformRandomBitGenerator</tt>,
<tt>invoke_­result_­t&lt;G&amp;&gt;</tt> is an unsigned integer type
(6.8.1 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>), and <tt>G</tt> provides a nested
<i>typedef-name</i> <tt>result_­type</tt> that denotes the same type as
<tt>invoke_­result_­t&lt;G&amp;&gt;</tt>.
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13; Prague]</i></p>

<p>
LWG provided some improved wording.
</p>
<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

<ol>
<li><p>Modify 26.6.2.3 <a href="https://wg21.link/rand.req.urng">[rand.req.urng]</a> as follows:</p>

<blockquote>
<p>1 A <i>uniform random bit generator</i> <tt>g</tt> of type <tt>G</tt> is a
function object returning unsigned integer values such that each value in the
range of possible results has (ideally) equal probability of being returned.
[<i>Note:</i> The degree to which <tt>g</tt>'s results approximate the ideal is
often determined statistically.&mdash;<i>end note</i>]
</p>
<blockquote>
<pre>
template&lt;class G&gt;
  concept uniform_random_bit_generator =
    invocable&lt;G&amp;&gt; &amp;&amp; unsigned_integral&lt;invoke_result_t&lt;G&amp;&gt;&gt; &amp;&amp;
    requires {
      { G::min() } -> same_as&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
      { G::max() } -> same_as&lt;invoke_result_t&lt;G&amp;&gt;&gt;;
      <ins>requires bool_constant&lt;(G::min() &lt; G::max())&gt;::value;</ins>
    };
</pre>
</blockquote>
<p>
-2- Let <tt>g</tt> be an object of type <tt>G</tt>. <tt>G</tt> models
<tt>uniform_random_bit_generator</tt> only if
</p><p>
<del>(2.1) &mdash; both <tt>G​::​min()</tt> and <tt>G​::​max()</tt> are constant
expressions (7.7 <a href="https://wg21.link/expr.const">[expr.const]</a>),</del>
</p><p>
<del>(2.2) &mdash; <tt>G​::​min() &lt; G​::​max()</tt>,</del>
</p><p>
(2.3) &mdash; <tt>G​::​min() &lt;= g()</tt>,
</p><p>
(2.4) &mdash; <tt>g() &lt;= G​::​max()</tt>, and
</p><p>
(2.5) &mdash; <tt>g()</tt> has amortized constant complexity.
</p><p>
3 A class <tt>G</tt> meets the <i>uniform random bit generator</i> requirements
if <tt>G</tt> models <tt>uniform_random_bit_generator</tt>,
<tt>invoke_­result_­t&lt;G&amp;&gt;</tt> is an unsigned integer type
(6.8.1 <a href="https://wg21.link/basic.fundamental">[basic.fundamental]</a>), and <tt>G</tt> provides a nested
<i>typedef-name</i> <tt>result_­type</tt> that denotes the same type as
<tt>invoke_­result_­t&lt;G&amp;&gt;</tt>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3175" href="#3175">3175</a><sup><a href="https://cplusplus.github.io/LWG/issue3175">(i)</a></sup>. The <tt>CommonReference</tt> requirement of concept <tt>SwappableWith</tt> is not satisfied in the example</h3>
<p><b>Section:</b> 18.4.9 <a href="https://wg21.link/concept.swappable">[concept.swappable]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Kostas Kyrimis <b>Opened:</b> 2018-12-14 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#concept.swappable">active issues</a> in [concept.swappable].</p>
<p><b>View all other</b> <a href="lwg-index.html#concept.swappable">issues</a> in [concept.swappable].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The defect stems from the example found in sub-clause 18.4.9 <a href="https://wg21.link/concept.swappable">[concept.swappable]</a> p5:
</p>
<blockquote>
<pre>
[&hellip;]

template&lt;class T, std::SwappableWith&lt;T&gt; U&gt;
void value_swap(T&amp;&amp; t, U&amp;&amp; u) {
  ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
}

[&hellip;]
namespace N {
  struct A { int m; };
  struct Proxy { A* a; };
  Proxy proxy(A&amp; a) { return Proxy{ &amp;a }; }
  
  void swap(A&amp; x, Proxy p) {
    ranges::swap(x.m, p.a-&gt;m);
  }
  void swap(Proxy p, A&amp; x) { swap(x, p); } <i>// satisfy symmetry requirement</i>
}

int main() {
  [&hellip;]
  N::A a1 = { 5 }, a2 = { -5 };
  value_swap(a1, proxy(a2)); // diagnostic manifests here(#1)
  assert(a1.m == -5 &amp;&amp; a2.m == 5);
}
</pre>
</blockquote>
<p>
The call to <tt>value_swap(a1, proxy(a2))</tt> resolves to [<tt>T</tt> = <tt>N::A&amp;</tt>, <tt>U</tt> = <tt>N::Proxy</tt>]
The compiler will issue a diagnostic for #1 because:
</p>
<ol>
<li><p>rvalue <tt>proxy(a2)</tt> is not swappable</p></li>
<li><p>concept <tt>SwappableWith&lt;T, U&gt;</tt> requires <tt>N::A</tt> and <tt>Proxy</tt> to model
<tt>CommonReference&lt;const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;&gt;</tt> It follows 
from the example that there is no common reference for [<tt>T</tt> = <tt>N::A&amp;</tt>, <tt>U</tt> = <tt>N::Proxy</tt>]</p></li>
</ol>

<p><i>[2019-06-20; Casey Carter comments and provides improved wording]</i></p>

<p>
The purpose of the <tt>CommonReference</tt> requirements in the cross-type concepts is to provide a 
sanity check. The fact that two types satisfy a single-type concept, have a common reference type 
that satisfies that concept, and implement cross-type operations required by the cross-type flavor 
of that concept very strongly suggests the programmer intends them to model the cross-type concept. 
It's an opt-in that requires some actual work, so it's unlikely to be inadvertent.
<p/>
The <tt>CommonReference&lt;const T&amp;, const U&amp;&gt;</tt> pattern makes sense for the comparison 
concepts which require that all variations of <tt>const</tt> and value category be comparable: we 
use <tt>const</tt> lvalues to trigger the "implicit expression variation" wording in 
18.2 <a href="https://wg21.link/concepts.equality">[concepts.equality]</a>. <tt>SwappableWith</tt>, however, doesn't care about implicit expression 
variations: it only needs to witness that we can exchange the values denoted by two reference-y 
expressions <tt>E1</tt> and <tt>E2</tt>. This suggests that <tt>CommonReference&lt;decltype((E1)), 
decltype((E2))&gt;</tt> is a more appropriate requirement than the current 
<tt>CommonReference&lt;const remove_reference_t&lt;&hellip;&gt;</tt> mess that was blindly copied 
from the comparison concepts.
<p/>
We must change the definition of "exchange the values" in 18.4.9 <a href="https://wg21.link/concept.swappable">[concept.swappable]</a> &mdash; 
which refers to the common reference type &mdash; consistently.
</p>

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

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

<blockquote>
<p>
-3- [&hellip;]
</p>
<blockquote>
<pre>
template&lt;class T&gt;
  concept Swappable = requires(T&amp; a, T&amp; b) { ranges::swap(a, b); };
  
template&lt;class T, class U&gt;
  concept SwappableWith =
  CommonReference&lt;<ins>T, U</ins><del>const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;</del>&gt; &amp;&amp;
  requires(T&amp;&amp; t, U&amp;&amp; u) {
    ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;T&gt;(t));
    ranges::swap(std::forward&lt;U&gt;(u), std::forward&lt;U&gt;(u));
    ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
    ranges::swap(std::forward&lt;U&gt;(u), std::forward&lt;T&gt;(t));
  };
</pre>
</blockquote>
<p>
-4- [&hellip;]
<p/>
-5- [<i>Example:</i> User code can ensure that the evaluation of <tt>swap</tt> calls is performed in an appropriate context
under the various conditions as follows:
</p>
<blockquote>
<pre>
#include &lt;cassert&gt;
#include &lt;concepts&gt;
#include &lt;utility&gt;

namespace ranges = std::ranges;

template&lt;class T, std::SwappableWith&lt;T&gt; U&gt;
void value_swap(T&amp;&amp; t, U&amp;&amp; u) {
  ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
}

template&lt;std::Swappable T&gt;
void lv_swap(T&amp; t1, T&amp; t2) {
  ranges::swap(t1, t2);
}

namespace N {
  struct A { int m; };
  struct Proxy { 
    A* a;
    <ins>Proxy(A&amp; a) : a{&amp;a} {}</ins>
    <ins>friend void swap(Proxy&amp;&amp; x, Proxy&amp;&amp; y) {
      ranges::swap(x.a, y.a);
    }</ins>
  };
  Proxy proxy(A&amp; a) { return Proxy{ &amp;a }; }
  void swap(A&amp; x, Proxy p) {
    ranges::swap(x.m, p.a->m);
  }
  void swap(Proxy p, A&amp; x) { swap(x, p); } // satisfy symmetry requirement
}

int main() {
  int i = 1, j = 2;
  lv_swap(i, j);
  assert(i == 2 &amp;&amp; j == 1);
  N::A a1 = { 5 }, a2 = { -5 };
  value_swap(a1, proxy(a2));
  assert(a1.m == -5 &amp;&amp; a2.m == 5);
}
</pre>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2020-01-16 Priority set to 1 after discussion on the reflector.]</i></p>


<p><i>[2020-02-10 Move to Immediate Monday afternoon in Prague]</i></p>



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

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

<blockquote>
<p>
-1- Let <tt>t1</tt> and <tt>t2</tt> be equality-preserving expressions that denote distinct equal objects 
of type <tt>T</tt>, and let <tt>u1</tt> and <tt>u2</tt> similarly denote distinct equal objects of type 
<tt>U</tt>. [<i>Note:</i> <tt>t1</tt> and <tt>u1</tt> can denote distinct objects, or the same object. 
&mdash; <i>end note</i>] An operation <i>exchanges the values</i> denoted by <tt>t1</tt> and <tt>u1</tt> if 
and only if the operation modifies neither <tt>t2</tt> nor <tt>u2</tt> and:
</p>
<ol style="list-style-type:none">
<li><p>(1.1) &mdash; If <tt>T</tt> and <tt>U</tt> are the same type, the result of the operation is that 
<tt>t1</tt> equals <tt>u2</tt> and <tt>u1</tt> equals <tt>t2</tt>.</p></li>
<li><p>(1.2) &mdash; If <tt>T</tt> and <tt>U</tt> are different types <del>that model 
<tt>CommonReference&lt;const T&amp;, const U&amp;&gt;</tt></del><ins>and 
<tt>CommonReference&lt;decltype((t1)), decltype((u1))&gt;</tt> is modeled</ins>, the result of the 
operation is that <tt>C(t1)</tt> equals <tt>C(u2)</tt> and <tt>C(u1)</tt> equals <tt>C(t2)</tt> where 
<tt>C</tt> is <tt>common_reference_t&lt;<del>const T&amp;, 
const U&amp;</del><ins>decltype((t1)), decltype((u1))</ins>&gt;</tt>.</p></li>
</ol>
<p>
-2- [&hellip;]
<p/>
-3- [&hellip;]
</p>
<blockquote>
<pre>
template&lt;class T&gt;
  concept Swappable = requires(T&amp; a, T&amp; b) { ranges::swap(a, b); };
  
template&lt;class T, class U&gt;
  concept SwappableWith =
  CommonReference&lt;<ins>T, U</ins><del>const remove_reference_t&lt;T&gt;&amp;, const remove_reference_t&lt;U&gt;&amp;</del>&gt; &amp;&amp;
  requires(T&amp;&amp; t, U&amp;&amp; u) {
    ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;T&gt;(t));
    ranges::swap(std::forward&lt;U&gt;(u), std::forward&lt;U&gt;(u));
    ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
    ranges::swap(std::forward&lt;U&gt;(u), std::forward&lt;T&gt;(t));
  };
</pre>
</blockquote>
<p>
-4- [&hellip;]
<p/>
-5- [<i>Example:</i> User code can ensure that the evaluation of <tt>swap</tt> calls is performed in an appropriate context
under the various conditions as follows:
</p>
<blockquote>
<pre>
#include &lt;cassert&gt;
#include &lt;concepts&gt;
#include &lt;utility&gt;

namespace ranges = std::ranges;

template&lt;class T, std::SwappableWith&lt;T&gt; U&gt;
void value_swap(T&amp;&amp; t, U&amp;&amp; u) {
  ranges::swap(std::forward&lt;T&gt;(t), std::forward&lt;U&gt;(u));
}

template&lt;std::Swappable T&gt;
void lv_swap(T&amp; t1, T&amp; t2) {
  ranges::swap(t1, t2);
}

namespace N {
  struct A { int m; };
  struct Proxy { 
    A* a;
    <ins>Proxy(A&amp; a) : a{&amp;a} {}</ins>
    <ins>friend void swap(Proxy x, Proxy y) {
      ranges::swap(*x.a, *y.a);
    }</ins>
  };
  Proxy proxy(A&amp; a) { return Proxy{ <del>&amp;</del>a }; }
  <del>void swap(A&amp; x, Proxy p) {
    ranges::swap(x.m, p.a->m);
  }
  void swap(Proxy p, A&amp; x) { swap(x, p); } <i>// satisfy symmetry requirement</i></del>
}

int main() {
  int i = 1, j = 2;
  lv_swap(i, j);
  assert(i == 2 &amp;&amp; j == 1);
  N::A a1 = { 5 }, a2 = { -5 };
  value_swap(a1, proxy(a2));
  assert(a1.m == -5 &amp;&amp; a2.m == 5);
}
</pre>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3200" href="#3200">3200</a><sup><a href="https://cplusplus.github.io/LWG/issue3200">(i)</a></sup>. <tt>midpoint</tt> should not constrain <tt>T</tt> is complete</h3>
<p><b>Section:</b> 25.9.15 <a href="https://wg21.link/numeric.ops.midpoint">[numeric.ops.midpoint]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Paolo Torres <b>Opened:</b> 2019-04-10 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The constraint of the <tt>midpoint</tt> overload in 25.9.15 <a href="https://wg21.link/numeric.ops.midpoint">[numeric.ops.midpoint]</a>:
</p>
<blockquote>
<pre>
template&lt;class T&gt;
constexpr T* midpoint(T* a, T* b);
</pre>
<blockquote>
<p>
-4- <i>Constraints:</i> <tt>T</tt> is a complete object type.
</p>
</blockquote>
</blockquote>
<p>
is incorrect. Paragraph 4 states <tt>T</tt> is constrained to be a complete object type, however it does not seem to 
be possible to implement <tt>T</tt> is complete. This means behavior is conditioned dependent on whether a type is 
complete, and this seems inconsistent with the library precedent.
</p>

<p><i>[2019-06-12 Priority set to 2 after reflector discussion]</i></p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

<ol>
<li><p>Modify 25.9.15 <a href="https://wg21.link/numeric.ops.midpoint">[numeric.ops.midpoint]</a> as indicated:</p>

<blockquote><pre>
template&lt;class T&gt;
  constexpr T* midpoint(T* a, T* b);
</pre>
<blockquote>
<p>
-4- <i>Constraints:</i> <tt>T</tt> is a<ins>n</ins> <del>complete</del> object type.
<p/>
<ins>-?- <i>Mandates:</i> <tt>T</tt> is a complete type.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3201" href="#3201">3201</a><sup><a href="https://cplusplus.github.io/LWG/issue3201">(i)</a></sup>. <tt>lerp</tt> should be marked as <tt>noexcept</tt></h3>
<p><b>Section:</b> 26.8.4 <a href="https://wg21.link/c.math.lerp">[c.math.lerp]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Paolo Torres <b>Opened:</b> 2019-04-10 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The overloads of <tt>lerp</tt> should be marked as <tt>noexcept</tt>, and this can be explained through the Lakos Rule. 
This function does not specify any undefined behaviour, and as such has no preconditions. This implies it has a wide 
contract, meaning it cannot throw, and thus can be marked as <tt>noexcept</tt>.
</p>

<p><i>[2020-02 Moved to Immediate on Thursday afternoon in Prague.]</i></p>



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

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

<blockquote>
<pre>
<i>// 26.8.4 <a href="https://wg21.link/c.math.lerp">[c.math.lerp]</a>, linear interpolation</i>
constexpr float lerp(float a, float b, float t) <ins>noexcept</ins>;
constexpr double lerp(double a, double b, double t) <ins>noexcept</ins>;
constexpr long double lerp(long double a, long double b, long double t) <ins>noexcept</ins>;
</pre>
</blockquote>
</li>

<li><p>Modify 26.8.4 <a href="https://wg21.link/c.math.lerp">[c.math.lerp]</a> as indicated:</p>

<blockquote>
<pre>
constexpr float lerp(float a, float b, float t) <ins>noexcept</ins>;
constexpr double lerp(double a, double b, double t) <ins>noexcept</ins>;
constexpr long double lerp(long double a, long double b, long double t) <ins>noexcept</ins>;
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3226" href="#3226">3226</a><sup><a href="https://cplusplus.github.io/LWG/issue3226">(i)</a></sup>. <tt>zoned_time</tt> constructor from <tt>string_view</tt> should accept
<tt>zoned_time&lt;Duration2, TimeZonePtr2&gt;</tt></h3>
<p><b>Section:</b> 27.11.7.2 <a href="https://wg21.link/time.zone.zonedtime.ctor">[time.zone.zonedtime.ctor]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-23 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#time.zone.zonedtime.ctor">issues</a> in [time.zone.zonedtime.ctor].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<code>zoned_time</code> constructors with <code>string_view</code> and
another <code>zoned_time</code> are not accepting <code>zoned_time</code>
instances that use a different time zone representation (<code>TimeZonePtr</code> parameter):
</p>
<blockquote><pre>
zoned_time(string_view name, const zoned_time&lt;Duration&gt;&amp; zt);
zoned_time(string_view name, const zoned_time&lt;Duration&gt;&amp; zt, choose);
</pre></blockquote>
<p>
This makes them inconsistent with the constructors from <code>TimeZonePtr</code> 
and <code>zoned_time</code>, that they delegate to: 
</p>
<blockquote><pre>
template&lt;class Duration2, class TimeZonePtr2&gt;
  zoned_time(TimeZonePtr z, const zoned_time&lt;Duration2, TimeZonePtr2&gt;&amp; zt);
template&lt;class Duration2, class TimeZonePtr2&gt;
  zoned_time(TimeZonePtr z, const zoned_time&lt;Duration2, TimeZonePtr2&gt;&amp; zt, choose);
</pre></blockquote>
<p>
Furthermore it forces the creation of a temporary <code>zoned_time</code> object in 
case when the source uses the same <code>TimeZonePtr</code>, but different <code>Duration</code>.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4820">N4820</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>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; zt);
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; zt, choose);</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; y);
</pre>
<blockquote>
<p>
-32- <i>Remarks:</i> This constructor does not participate in overload resolution unless 
<tt>zoned_time</tt> is constructible from the return type of <tt>traits::locate_zone(name)</tt> 
and <tt>zoned_time<ins>&lt;Duration2, TimeZonePtr2&gt;</ins></tt>.
<p/>
-33- <i>Effects:</i> Equivalent to construction with <tt>{traits::locate_zone(name), y}</tt>.
</p>
</blockquote>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; y, choose c););
</pre>
<blockquote>
<p>
-34- <i>Remarks:</i> This constructor does not participate in overload resolution unless 
<tt>zoned_time</tt> is constructible from the return type of <tt>traits::locate_zone(name)</tt>, 
<tt>zoned_time<ins>&lt;Duration2, TimeZonePtr2&gt;</ins></tt>, and <tt>choose</tt>.
<p/>
-35- <i>Effects:</i> Equivalent to construction with <tt>{traits::locate_zone(name), y, c}</tt>.
<p/>
-36- [<i>Note:</i> The <tt>choose</tt> parameter has no effect. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
During LWG discussions it was suggested to rebase the wording to reduce the chances for confusion.
</p>
<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4849">N4849</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>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; zt);
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; zt, choose);</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; y);
</pre>
<blockquote>
<p>
-32- <i>Constraints:</i> <tt>zoned_time</tt> is constructible from the return type of <tt>traits::locate_zone(name)</tt> 
and <tt>zoned_time<ins>&lt;Duration2, TimeZonePtr2&gt;</ins></tt>.
<p/>
-33- <i>Effects:</i> Equivalent to construction with <tt>{traits::locate_zone(name), y}</tt>.
</p>
</blockquote>
<pre>
<ins>template&lt;class Duration2, class TimeZonePtr2&gt;</ins>
zoned_time(string_view name, const zoned_time&lt;Duration<ins>2, TimeZonePtr2</ins>&gt;&amp; y, choose c););
</pre>
<blockquote>
<p>
-34- <i>Constraints:</i> <tt>zoned_time</tt> is constructible from the return type of <tt>traits::locate_zone(name)</tt>, 
<tt>zoned_time<ins>&lt;Duration2, TimeZonePtr2&gt;</ins></tt>, and <tt>choose</tt>.
<p/>
-35- <i>Effects:</i> Equivalent to construction with <tt>{traits::locate_zone(name), y, c}</tt>.
<p/>
-36- [<i>Note:</i> The <tt>choose</tt> parameter has no effect. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3237" href="#3237">3237</a><sup><a href="https://cplusplus.github.io/LWG/issue3237">(i)</a></sup>. LWG 3038 and 3190 have inconsistent PRs</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#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-07-18 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Both LWG <a href="lwg-defects.html#3038">3038</a> and LWG <a href="lwg-defects.html#3190">3190</a> deal with how to respond to requests to allocate 
"<tt>n * sizeof(T)</tt>" bytes of memory when <tt>n * sizeof(T)</tt> is not sufficient storage for 
<tt>n</tt> objects of type <tt>T</tt>, i.e., when <tt>n &gt; SIZE_MAX / sizeof(T)</tt>. LWG 
<a href="lwg-defects.html#3038">3038</a> changed <tt>polymorphic_allocator::allocate</tt> to throw <tt>length_error</tt> upon 
detecting this condition, whereas LWG <a href="lwg-defects.html#3190">3190</a> changed <tt>allocator::allocate</tt> to 
throw <tt>bad_array_new_length</tt>. It's peculiar that two standard library components which allocate 
memory both detect this condition but handle it by throwing different exception types; for consistency, 
the two should be harmonized.
<p/>
Reflector discussion of 3190 seemed to achieve consensus that <tt>bad_array_new_length</tt> was 
the better option. Unlike <tt>length_error</tt>, <tt>bad_array_new_length</tt> derives from 
<tt>bad_alloc</tt> so we can make this change without altering the invariant that allocation functions 
either succeed or throw an exception derived from <tt>bad_alloc</tt>.
<p/>
Further, <a href="http://wg21.link/p0339r6">P0339R6</a> "<tt>polymorphic_allocator&lt;&gt;</tt> as a 
vocabulary type" recently added the function template "<tt>template&lt;class T&gt; T* 
allocate_object(size_t n = 1);</tt>" to <tt>std::pmr::polymorphic_allocator</tt>, which is another 
instance of the "allocate memory for <tt>n</tt> objects of type <tt>T</tt>" pattern. 
20.12.3.2 <a href="https://wg21.link/mem.poly.allocator.mem">[mem.poly.allocator.mem]</a> paragraph 8.1 specifies that <tt>allocate_object</tt> throws 
<tt>length_error</tt> when <tt>SIZE_MAX / sizeof(T) &lt; n</tt>, presumably for consistency with <tt>std::pmr::polymorphic_allocator::allocate</tt> specified in paragraph 1. <tt>allocate_object</tt>'s 
behavior should be consistent with <tt>allocator::allocate</tt> and 
<tt>polymorphic_allocator::allocate</tt> so we have a single means of communicating "request for 
allocation of unrepresentable size" errors in the Standard Library.
</p>

<p><i>[2020-02 Moved to Immediate on Thursday afternoon in Prague.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4820">N4820</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>SIZE_MAX / sizeof(Tp) &lt; n</tt>, throws 
<tt><del>length_error</del><ins>bad_array_new_length</ins></tt>. 
Otherwise equivalent to:
</p>
<blockquote><pre>
return static_cast&lt;Tp*&gt;(memory_rsrc-&gt;allocate(n * sizeof(Tp), alignof(Tp)));
</pre>
</blockquote>
</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:
</p>
<ol style="list-style-type: none">
<li><p>(8.1) &mdash; if <tt>SIZE_MAX / sizeof(T) &lt; n</tt>, throws 
<tt><del>length_error</del><ins>bad_array_new_length</ins></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>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3238" href="#3238">3238</a><sup><a href="https://cplusplus.github.io/LWG/issue3238">(i)</a></sup>. Insufficiently-defined behavior of <tt>std::function</tt> deduction guides</h3>
<p><b>Section:</b> 20.14.16.2.1 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Louis Dionne <b>Opened:</b> 2019-07-17 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func.con">active issues</a> in [func.wrap.func.con].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.con">issues</a> in [func.wrap.func.con].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code is currently undefined behavior:
</p>
<blockquote><pre>
#include &lt;functional&gt;

struct R { };
struct f0 { R operator()() &amp;&amp; { return {}; } };

int main() { std::function f = f0{}; }
</pre></blockquote>
<p>
The reason is that 20.14.16.2.1 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a>/12 says:
</p>
<blockquote><p>
This deduction guide participates in overload resolution only if <tt>&amp;F::operator()</tt> is well-formed 
when treated as an unevaluated operand. In that case, if <tt>decltype(&amp;F::operator())</tt> is of the 
form <tt>R(G::*)(A...) <i>cv</i> &amp;<sub><i>opt</i></sub> noexcept<sub><i>opt</i></sub></tt> for a 
class type <tt>G</tt>, then the deduced type is <tt>function&lt;R(A...)&gt;</tt>.
</p></blockquote>
<p>
However, it does not define the behavior when <tt>&amp;F::operator()</tt> is well-formed but <em>not</em> 
of the required form (in the above example it's of the form <tt>R(G::*)(A...) &amp;&amp;</tt>, which is 
rvalue-reference qualified instead of optionally-lvalue-reference qualified). libc++'s implementation 
of the deduction guide SFINAE's out when either <tt>&amp;F::operator()</tt> is not well-formed, or it 
is not of the required form. It seems like mandating that behavior in the Standard is the way to go.
</p>

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

<ol>
<li><p>Modify 20.14.16.2.1 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F) -&gt; function&lt;<i>see below</i>&gt;;
</pre><blockquote>
<p>
-12- <i>Remarks:</i> This deduction guide participates in overload resolution only if 
<tt>&amp;F::operator()</tt> is well-formed when treated as an unevaluated operand<ins>, and its type is 
of the form <tt>R(G::*)(A...) <i>cv</i> &amp;<sub><i>opt</i></sub> noexcept<sub><i>opt</i></sub></tt> 
for a class type <tt>G</tt> and a sequence of types <tt>A...</tt></ins>. 
In that case, <del>if <tt>decltype(&amp;F::operator())</tt> is of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub><i>opt</i></sub> noexcept<sub><i>opt</i></sub></tt> for a class type <tt>G</tt>, 
then</del> the deduced type is <tt>function&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13; Prague]</i></p>

<p>
LWG improves wording matching Marshall's Mandating paper.
</p>
<p><i>[Status to Immediate on Friday in Prague.]</i></p>



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

<ol>
<li><p>Modify 20.14.16.2.1 <a href="https://wg21.link/func.wrap.func.con">[func.wrap.func.con]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> This edit should be used instead of the corresponding edit in <a href="http://wg21.link/p1460">P1460</a>]
</p>
</blockquote>

<blockquote>
<pre>
template&lt;class F&gt; function(F) -&gt; function&lt;<i>see below</i>&gt;;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> <tt>&amp;F::operator()</tt> is well-formed when treated as an unevaluated operand 
and <tt>decltype(&amp;F::operator())</tt> is of the form <tt>R(G::*)(A...) <i>cv</i> &amp;<sub><i>opt</i></sub> 
noexcept<sub><i>opt</i></sub></tt> for a class type <tt>G</tt>.</ins>
<p/>
-12- <i>Remarks:</i> <del>This deduction guide participates in overload resolution only if 
<tt>&amp;F::operator()</tt> is well-formed when treated as an unevaluated operand. 
In that case, if <tt>decltype(&amp;F::operator())</tt> is of the form <tt>R(G::*)(A...) <i>cv</i> 
&amp;<sub><i>opt</i></sub> noexcept<sub><i>opt</i></sub></tt> for a class type <tt>G</tt>, 
then t</del><ins>T</ins>he deduced type is <tt>function&lt;R(A...)&gt;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3242" href="#3242">3242</a><sup><a href="https://cplusplus.github.io/LWG/issue3242">(i)</a></sup>. <tt>std::format</tt>: missing rules for <tt>arg-id</tt> in <tt>width</tt> and <tt>precision</tt></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#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-07-31 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>1
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to 20.20.2 <a href="https://wg21.link/format.string">[format.string]</a> we have:
</p>
<blockquote><p>
If the numeric <tt>arg-id</tt>s in a format string are <tt>0, 1, 2, ...</tt> in sequence, they can all be 
omitted (not just some) and the numbers <tt>0, 1, 2, ...</tt> will be automatically used in that order. 
A format string does not contain a mixture of automatic and manual indexing.
</p></blockquote>
<p>
&hellip; but what does that mean in the presence of <tt>arg-id</tt> in <tt>width</tt> and <tt>precision</tt>? 
Can one replace
</p>
<blockquote><pre>
"{0:{1}} {2}"
</pre></blockquote>
<p>
with
</p>
<blockquote><pre>
"{:{}} {}"
</pre></blockquote>
<p>
? The grammar says the answer is no, because the <tt>arg-id</tt> in <tt>width</tt> is not optional, but 
the normative wording says the answer is yes.
<p/>
<b>Victor Zverovich:</b>
<p/>
That's a bug in the grammar. The <tt>arg-id</tt> should be optional in <tt>width</tt> and <tt>precision</tt>:
</p>
<blockquote>
<pre>
width     ::= nonzero-digit [integer] | '{' [arg-id] '}'
precision ::= integer | '{' [arg-id] '}'
</pre>
</blockquote>

<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</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 the <tt><i>width</i></tt> and <tt><i>precision</i></tt> grammar in the syntax 
of format specifications of 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<blockquote>
<pre>
[&hellip;]
<i>width:</i>
         <i>positive-integer</i>
         { <i>arg-id<ins><sub>opt</sub></ins></i> }
<i>precision:</i>
         . <i>nonnegative-integer</i>  
         . { <i>arg-id<ins><sub>opt</sub></ins></i> }   
[&hellip;]         
</pre>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<p>
-6- The <i>#</i> option causes [&hellip;]
<p/>
<ins>-?- If <tt>{ <i>arg-id<sub>opt</sub></i> }</tt> is used in a <i>width</i> or <i>precision</i>, 
the value of the corresponding formatting argument is used in its place. If the corresponding 
formatting argument is not of integral type, or its value is negative for <i>precision</i> or 
non-positive for <i>width</i>, an exception of type <tt>format_error</tt> is thrown.</ins>
<p/>
-7- The <i>positive-integer</i> in <i>width</i> is a decimal integer defining the minimum field width. 
If <i>width</i> is not specified, there is no minimum field width, and the field width is determined 
based on the content of the field.
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3243" href="#3243">3243</a><sup><a href="https://cplusplus.github.io/LWG/issue3243">(i)</a></sup>. <tt>std::format</tt> and negative zeroes</h3>
<p><b>Section:</b> 20.20.2 <a href="https://wg21.link/format.string">[format.string]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-07-31 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#format.string">active issues</a> in [format.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#format.string">issues</a> in [format.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
What are these:
</p>
<blockquote><pre>
std::format("{}", -0.0);
std::format("{:+}", -0.0);
std::format("{:-}", -0.0);
std::format("{: }", -0.0);
</pre></blockquote>
<p>
with
</p>
<blockquote><pre>
"{:{}} {}"
</pre></blockquote>
<p>
A negative zero is not a negative number, so I <em>think</em> the answer for an implementation that supports 
signed zeroes is <tt>"0"</tt>, <tt>"-0"</tt>, <tt>"0"</tt>, <tt>" 0"</tt>. Is that the intent? (Note 
that this doesn't satisfy <tt>to_chars</tt>' round-trip guarantee.)
<p/>
Or should the behavior actually be that <tt>"+"</tt> means "insert a leading <tt>+</tt> if <tt>to_chars</tt>' 
output does not start with <tt>-"</tt> and <tt>" "</tt> actually means "insert a leading space if 
<tt>to_chars</tt>' output does not start with <tt>-"</tt> (that is, the same as <tt>"%+f"</tt> and <tt>"% f"</tt>) 
&mdash; so that the result of all four calls is <tt>"-0"</tt>?
<p/>
<b>Victor Zverovich:</b>
<p/>
The latter. <tt>std::format</tt> is specified in terms of <tt>to_chars</tt> and the intent is to have similar 
round trip guarantee here, so the result should be <tt>"-0"</tt>, <tt>"-0"</tt>, <tt>"-0"</tt>, <tt>"-0"</tt>. 
This has also been extensively discussed in LEWG and the outcome of that discussion was to print <tt>'-'</tt> 
for negative zeros.
<p/>
So I think it should be clarified that <tt>'-'</tt> and space apply to negative numbers and negative zero.
</p>

<p><i>[2019-08-17 Priority set to 2 based on reflector discussion]</i></p>


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

<ol>
<li><p>Modify the <i>sign</i> options Table [tab:format.sign] in 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 59: Meaning of <i>sign</i> options [tab:format.sign]</caption>
<tr align="center">
<th>Option</th>
<th>Meaning</th>
</tr> 

<tr>
<td>
<tt>'+'</tt>
</td>
<td>
Indicates that a sign should be used for both non-negative and negative numbers.
</td>
</tr>

<tr>
<td>
<tt>'-'</tt>
</td>
<td>
Indicates that a sign should be used only for negative numbers <ins>and negative zero</ins> 
(this is the default behavior).
</td>
</tr>

<tr>
<td>
space
</td>
<td>
Indicates that a leading space should be used for non-negative numbers <ins>other than negative 
zero</ins>, and a minus sign for negative numbers <ins>and negative zero</ins>.
</td>
</tr>

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

</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Rebased and some wording finetuning by LWG.
</p>
<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

<ol>
<li><p>Modify the <i>sign</i> options Table [tab:format.sign] in 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 58: Meaning of <i>sign</i> options [tab:format.sign]</caption>
<tr align="center">
<th>Option</th>
<th>Meaning</th>
</tr> 

<tr>
<td>
<tt>'+'</tt>
</td>
<td>
Indicates that a sign should be used for both non-negative and negative numbers.
</td>
</tr>

<tr>
<td>
<tt>'-'</tt>
</td>
<td>
Indicates that a sign should be used <del>only</del> for negative numbers <ins>and negative zero only</ins> 
(this is the default behavior).
</td>
</tr>

<tr>
<td>
space
</td>
<td>
Indicates that a leading space should be used for non-negative numbers <ins>other than negative 
zero</ins>, and a minus sign for negative numbers <ins>and negative zero</ins>.
</td>
</tr>

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

</ol>




<hr>
<h3><a name="3247" href="#3247">3247</a><sup><a href="https://cplusplus.github.io/LWG/issue3247">(i)</a></sup>. <tt>ranges::iter_move</tt> should perform ADL-only lookup of <tt>iter_move</tt></h3>
<p><b>Section:</b> 23.3.3.1 <a href="https://wg21.link/iterator.cust.move">[iterator.cust.move]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-07-29 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The specification of the <tt>ranges::iter_move</tt> customization point in [iterator.cust.move] 
doesn't include a deleted poison pill overload. There is no <tt>std::iter_move</tt> to avoid, 
so such a poison pill is not needed. This is fine, except that it suggests that unqualified 
lookup for <tt>iter_move</tt> in the <tt>iter_move(E)</tt> expression in paragraph 1.1 should 
find declarations of iter_move in the global namespace via normal unqualified lookup, when the 
design intent is that only ADL be used to find overloads of <tt>iter_move</tt>.
<p/>
Absent a more idiomatic wording to specify an ADL-only lookup, we can correct the problem by 
specifying the lookup in paragraph 1.1 is performed in a context that includes the declaration 
"<tt>void iter_move();</tt>" which has the desired effect.
</p>

<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</i></p>



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

<blockquote class="note">
<p>
[<i>Drafting Note:</i> There's a drive-by fix here to change "valid" &mdash; which suggests runtime behavior 
which cannot be validated at compile time &mdash; to "well-formed".]
</p>
</blockquote>

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

<blockquote>
<p>
-1- The name <tt>ranges::iter_move</tt> denotes a customization point object (16.4.2.2.6 <a href="https://wg21.link/customization.point.object">[customization.point.object]</a>). The expression <tt>ranges::iter_move(E)</tt> for 
some subexpression <tt>E</tt> is expression-equivalent to:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>iter_move(E)</tt>, if that expression is <del>valid</del><ins>well-formed 
when treated as an unevaluated operand</ins>, with overload resolution 
performed in a context that does not include a declaration of <tt>ranges::iter_move</tt><del>.</del> 
<ins>but does include the declaration:</ins></p>
<pre>
   <ins>void iter_move();</ins>
</pre></li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3248" href="#3248">3248</a><sup><a href="https://cplusplus.github.io/LWG/issue3248">(i)</a></sup>. <tt>std::format</tt> <tt>#b</tt>, <tt>#B</tt>, <tt>#o</tt>, <tt>#x</tt>, and <tt>#X</tt> 
presentation types misformat negative numbers</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#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-08-01 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
According to both the specification for <tt>'#'</tt> and the presentation types <tt>b</tt>, <tt>B</tt>, 
<tt>o</tt>, <tt>x</tt>, and <tt>X</tt> (which redundantly duplicate the rule for the relevant prefixes), 
the string <tt>0b</tt>, <tt>0B</tt>, <tt>0</tt>, <tt>0x</tt>, or <tt>0X</tt> is prefixed to the result 
of <tt>to_chars</tt>. That means:
</p>
<blockquote><pre>
std::format("{0:#b} {0:#B} {0:#o} {0:#x} {0:#X}", -1)
</pre></blockquote>
<p>
produces
</p>
<blockquote><pre>
"0b-1 0B-1 0-1 0x-1 0X-1"
</pre></blockquote>
<p>
I assume that's a bug?
<p/>
(Additionally, if the <tt>+</tt> specifier is used, there appears to be no specification of where 
the sign is inserted into the output.)
<p/>
<b>Victor Zverovich:</b>
<p/>
Yes. I suggest replacing
</p>
<blockquote><p>
adds the respective prefix <tt>"0b"</tt> (<tt>"0B"</tt>), <tt>"0"</tt>, or <tt>"0x"</tt> (<tt>"0X"</tt>) 
to the output value
</p></blockquote>
<p>
with something like 
</p>
<blockquote><p>
inserts the respective prefix <tt>"0b"</tt> (<tt>"0B"</tt>), <tt>"0"</tt>, or <tt>"0x"</tt> (<tt>"0X"</tt>) 
to the output value after the sign, if any,
</p></blockquote>
<p>
I think the duplicate wording in the presentation types <tt>b</tt>, <tt>B</tt>, <tt>o</tt>, <tt>x</tt>, and 
<tt>X</tt> can be dropped.
<p/>
Regarding the <tt>+</tt> specifier problem: How about adding
</p>
<blockquote><p>
The sign is inserted before the output of <tt>to_chars</tt>.
</p></blockquote>
<p>
?
</p>

<p><i>[2019-08-21 Priority set to 2 based on reflector discussion]</i></p>


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

<ol>
<li><p>Modify the <i>sign</i> options Table [tab:format.sign] in 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 59: Meaning of <i>sign</i> options [tab:format.sign]</caption>
<tr align="center">
<th>Option</th>
<th>Meaning</th>
</tr> 

<tr>
<td>
<tt>'+'</tt>
</td>
<td>
Indicates that a sign should be used for both non-negative and negative numbers. <ins>The sign is 
inserted before the output of <tt>to_chars</tt>.</ins>
</td>
</tr>

<tr>
<td>
<tt>'-'</tt>
</td>
<td>
Indicates that a sign should be used only for negative numbers (this is the default behavior).
</td>
</tr>

<tr>
<td>
space
</td>
<td>
Indicates that a leading space should be used for non-negative numbers, and a minus
sign for negative numbers.
</td>
</tr>

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

<li><p>Modify [format.string] as indicated:</p>

<blockquote>
<p>
-6 The <tt>#</tt> option causes the <i>alternate form</i> to be used for the conversion. This option 
is only valid for arithmetic types other than <tt>charT</tt> and <tt>bool</tt> or when an integer 
presentation type is specified. For integral types, the alternate form <del>adds</del><ins>inserts</ins> 
the base prefix (if any) specified in Table [tab:format.type.int] to the output value <ins>after the 
sign, if any</ins>. [&hellip;]
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2019-08-21; Victor Zverovich provides improved wording]</i></p>


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

<ol>
<li><p>Modify the <i>sign</i> options Table [tab:format.sign] in 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 59: Meaning of <i>sign</i> options [tab:format.sign]</caption>
<tr align="center">
<th>Option</th>
<th>Meaning</th>
</tr> 

<tr>
<td>
<tt>'+'</tt>
</td>
<td>
Indicates that a sign should be used for both non-negative and negative numbers. <ins>The <tt>+</tt> 
sign is inserted before the output of <tt>to_chars</tt> for non-negative numbers other than 
the negative zero. [<i>Note:</i> For negative numbers and the negative zero the output of 
<tt>to_chars</tt> will already contain the sign so no additional transformation is performed. &mdash; 
<i>end note</i>]</ins>
</td>
</tr>

<tr>
<td>
<tt>'-'</tt>
</td>
<td>
Indicates that a sign should be used only for negative numbers (this is the default behavior).
</td>
</tr>

<tr>
<td>
space
</td>
<td>
Indicates that a leading space should be used for non-negative numbers, and a minus
sign for negative numbers.
</td>
</tr>

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

<li><p>Modify [format.string] as indicated:</p>

<blockquote>
<p>
-6- The <tt>#</tt> option causes the <i>alternate form</i> to be used for the conversion. This option 
is only valid for arithmetic types other than <tt>charT</tt> and <tt>bool</tt> or when an integer 
presentation type is specified. For integral types, the alternate form <del>adds</del><ins>inserts</ins> 
the base prefix (if any) specified in Table [tab:format.type.int] to the output value <ins>after the 
sign character (possibly space) if there is one, or before the output of <tt>to_chars</tt> otherwise</ins>. 
[&hellip;]
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
LWG made some improvements to the wording.
</p>
<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

<ol>
<li><p>Modify the <i>sign</i> options Table [tab:format.sign] in 20.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 58: Meaning of <i>sign</i> options [tab:format.sign]</caption>
<tr align="center">
<th>Option</th>
<th>Meaning</th>
</tr> 

<tr>
<td>
<tt>'+'</tt>
</td>
<td>
Indicates that a sign should be used for both non-negative and negative numbers. <ins>The <tt>+</tt> 
sign is inserted before the output of <tt>to_chars</tt> for non-negative numbers other than 
negative zero. [<i>Note:</i> For negative numbers and negative zero the output of 
<tt>to_chars</tt> will already contain the sign so no additional transformation is performed. &mdash; 
<i>end note</i>]</ins>
</td>
</tr>

<tr>
<td>
<tt>'-'</tt>
</td>
<td>
Indicates that a sign should be used only for negative numbers (this is the default behavior).
</td>
</tr>

<tr>
<td>
space
</td>
<td>
Indicates that a leading space should be used for non-negative numbers, and a minus
sign for negative numbers.
</td>
</tr>

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

<li><p>Modify [format.string] as indicated:</p>

<blockquote>
<p>
-6- The <tt>#</tt> option causes the <i>alternate form</i> to be used for the conversion. This option 
is <del>only</del> valid for arithmetic types other than <tt>charT</tt> and <tt>bool</tt> or when an integer 
presentation type is specified<ins>, and not otherwise</ins>. For integral types, the alternate form 
<del>adds</del><ins>inserts</ins> the base prefix (if any) specified in Table [tab:format.type.int] 
<del>to</del><ins>into</ins> the output <del>value</del> <ins>after the sign character (possibly space) 
if there is one, or before the output of <tt>to_chars</tt> otherwise</ins>. 
[&hellip;]
</p>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3250" href="#3250">3250</a><sup><a href="https://cplusplus.github.io/LWG/issue3250">(i)</a></sup>. <tt>std::format</tt>: <tt>#</tt> (alternate form) for NaN and inf</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#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-08-05 <b>Last modified:</b> 2020-02-13</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We have:
</p>
<blockquote><p>
"For floating-point numbers, the alternate form causes the result of the conversion to always contain a decimal-point character, even if no digits follow it."
</p></blockquote>
<p>
So does that mean that infinity is formatted as <tt>"inf."</tt> and NaN as <tt>"nan."</tt>? (Or 
something like that? Where exactly do we add the decimal point in this case?) Or does this 
affect infinity but not NaN (because we can handwave that a NaN value is not a 
"floating-point number")?
<p/>
I suspect that this should only cover finite floating-point numbers.
<p/>
<b>Victor Zverovich:</b>
<p/>
Right. So infinity and NaN should be still formatted as <tt>"inf"</tt> and <tt>"nan"</tt> 
without a decimal point.
</p>

<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</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.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<p>
-6- [&hellip;] For floating-point types, the alternate form causes the result of the conversion 
<ins>of finite values</ins> to always contain a decimal-point character, even if no digits follow 
it. Normally, a decimal-point character appears in the result of these conversions only if a digit 
follows it. In addition, for <tt>g</tt> and <tt>G</tt> conversions, trailing zeros are not removed 
from the result.
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3251" href="#3251">3251</a><sup><a href="https://cplusplus.github.io/LWG/issue3251">(i)</a></sup>. Are <tt>std::format</tt> alignment specifiers applied to string arguments?</h3>
<p><b>Section:</b> 20.20.2 <a href="https://wg21.link/format.string">[format.string]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-08-02 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#format.string">active issues</a> in [format.string].</p>
<p><b>View all other</b> <a href="lwg-index.html#format.string">issues</a> in [format.string].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We are told:
</p>
<blockquote><p>
Formatting of objects of arithmetic types and <tt>const void*</tt> is done as if by 
calling <tt>to_chars</tt> (unless otherwise specified) and copying the output through 
the output iterator of the format context with additional padding and adjustments 
as specified by the format specifiers.
</p></blockquote>
<p>
&hellip; but there is no corresponding rule for strings. Is an alignment specifier 
intended to be applied to strings or not? The wording as-is is ambiguous.
<p/>
(The above also doesn't cover formatting <tt>void*</tt> or <tt>std::nullptr_t</tt>. 
Presumably at least those two should have the relevant adjustments applied to them!)
<p/>
The wording never actually anywhere says that the <tt>basic_format_args</tt> are in 
any way involved in the formatting process, or how formatting actually happens. 
(The wording doesn't say that <tt>basic_format_arg::handle::format</tt> is ever 
called, for example.)
<p/>
<b>Victor Zverovich:</b>
<p/>
An alignment specifier is intended to be applied to strings as well, <tt>void*</tt> and 
<tt>std::nullptr_t</tt> are converted into <tt>const void*</tt> when constructing 
<tt>basic_format_arg</tt>.
<p/>
The wording for <tt>vformat</tt> and similar functions says that <tt>basic_format_args</tt> is involved:
</p>
<blockquote><p>
<i>Returns:</i> A string object holding the character representation of formatting arguments
 provided by <tt>args</tt> formatted according to specifications given in <tt>fmt</tt>.
</p></blockquote>
<p>
but I admit that it is hand-wavy. Perhaps we could add something along the lines of
</p>
<blockquote><p>
For each replacement field referring to the argument with index <tt>(arg-id) i</tt>, the 
<tt>basic_format_arg</tt> object referring to the argument is obtained via <tt>args.get(i)</tt> 
and the <tt>parse</tt> and <tt>format</tt> functions of the <tt>formatter</tt> specialization 
for the underlying argument type are called to parse the format specification and format the value.
</p></blockquote>
<p>
to clarify how we format <tt>args</tt> (<tt>basic_format_args</tt>).
</p>

<p><i>[2019-08-21 Priority set to 2 based on reflector discussion]</i></p>


<p><i>[2019-08-21; Victor Zverovich suggests wording]</i></p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</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.20.2.2 <a href="https://wg21.link/format.string.std">[format.string.std]</a> as indicated:</p>

<blockquote>
<p>
-3- <ins>The <i>align</i> specifier applies to all argument types.</ins> The meaning of the 
various alignment options is as specified in Table [tab:format.align]. 
[<i>Example:</i> [&hellip;
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3252" href="#3252">3252</a><sup><a href="https://cplusplus.github.io/LWG/issue3252">(i)</a></sup>. Parse locale's aware modifiers for commands are not consistent
with POSIX spec</h3>
<p><b>Section:</b> 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-08-06 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.parse">active issues</a> in [time.parse].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.parse">issues</a> in [time.parse].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification of the locale modifiers for the parse flags in
"[tab:time.parse.spec] Meaning of <code>parse</code> flags" is
inconsistent with the <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html">
POSIX <code>strptime</code> specification</a>:
</p>
<ul>
<li><p>New flags <code>%OC</code>, <code>%Ou</code> are added</p></li>
<li><p>Flags <code>%OI</code>, <code>%OU</code>, <code>%OW</code> are missing</p></li>
</ul>
<p>
Per Howard's comment:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
I only invented in a couple places for these flags, and none of them
involved locale-dependent stuff. If we are inconsistent with POSIX/C on
this, it's a bug. Rationale, <code>std::get_time</code> is already 
specified in terms of <code>strptime</code>, and we can't afford to be 
inventive with locale-dependent things.
</blockquote>
<p>
Note that, due above, the inconsistency between <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html">
POSIX <code>strftime</code> specification</a> that supports <code>%Ou</code> 
and <code>%OV</code> that are not handled by <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html">
<code>strptime</code></a> should be (by design) reflected in "[tab:time.format.spec] 
Meaning of conversion specifiers" and "[tab:time.parse.spec] Meaning of
<code>parse</code> flags" tables.
<p/>
The <code>%d</code> modifier was addressed by LWG <a href="lwg-defects.html#3218">3218</a>.
</p>
<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</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 Table 99 "Meaning of <tt>parse</tt> flags [tab:time.parse.spec]" in
27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 99: Meaning of <tt>parse</tt> flags [tab:time.parse.spec]</caption>
<tr align="center">
<th>Flag</th>
<th>Parsed value</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>%C</tt>
</td>
<td>
The century as a decimal number. The modified command <tt>%<i>N</i>C</tt> specifies the maximum
number of characters to read. If <tt><i>N</i></tt> is not specified, the default is <tt>2</tt>. 
Leading zeroes are permitted but not required. The modified command<del>s</del> <tt>%EC</tt> 
<del>and <tt>%OC</tt></del> interpret<ins>s</ins> the locale's alternative representation of 
the century.
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>%I</tt>
</td>
<td>
The hour (12-hour clock) as a decimal number. The modified command <tt>%<i>N</i>I</tt> specifies
the maximum number of characters to read. If <tt><i>N</i></tt> is not specified, the default is <tt>2</tt>.
Leading zeroes are permitted but not required. <ins>The modified command <tt>%OI</tt> interprets 
the locale's alternative representation.</ins>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>%u</tt>
</td>
<td>
The ISO weekday as a decimal number (<tt>1-7</tt>), where Monday is <tt>1</tt>. The modified
command <tt>%<i>N</i>u</tt> specifies the maximum number of characters to read. If <tt><i>N</i></tt> 
is not specified, the default is <tt>1</tt>. Leading zeroes are permitted but not required. 
<del>The modified command <tt>%Ou</tt> interprets the locale's alternative representation.</del>
</td>
</tr>

<tr>
<td>
<tt>%U</tt>
</td>
<td>
The week number of the year as a decimal number. The first Sunday of the year is the
first day of week <tt>01</tt>. Days of the same year prior to that are in week <tt>00</tt>. 
The modified command <tt>%<i>N</i>U</tt> specifies the maximum number of characters to read. 
If <tt><i>N</i></tt> is not specified, the default is <tt>2</tt>. Leading zeroes are permitted 
but not required. <ins>The modified command <tt>%OU</tt> interprets the locale's
alternative representation.</ins>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>%W</tt>
</td>
<td>
The week number of the year as a decimal number. The first Monday of the year is the
first day of week <tt>01</tt>. Days of the same year prior to that are in week <tt>00</tt>. 
The modified command <tt>%<i>N</i>W</tt> specifies the maximum number of characters to read. 
If <tt><i>N</i></tt> is not specified, the default is <tt>2</tt>. Leading zeroes are permitted 
but not required. <ins>The modified command <tt>%OW</tt> interprets the locale's
alternative representation.</ins>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3255" href="#3255">3255</a><sup><a href="https://cplusplus.github.io/LWG/issue3255">(i)</a></sup>. <tt>span</tt>'s <tt>array</tt> constructor is too strict</h3>
<p><b>Section:</b> 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jean Guegant &amp; Barry Revzin <b>Opened:</b> 2019-08-10 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#span.cons">active issues</a> in [span.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#span.cons">issues</a> in [span.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<b>Barry Revzin:</b>
<p/>
From <a href="https://stackoverflow.com/q/57444188/2069064">StackOverflow</a>:
<p/>
This compiles:
</p>
<blockquote><pre>
std::vector&lt;int*&gt; v = {nullptr, nullptr};
std::span&lt;const int* const&gt; s{v};
</pre></blockquote>
<p>
This does not:
</p>
<blockquote><pre>
std::array&lt;int*, 2&gt; a = {nullptr, nullptr};
std::span&lt;const int* const&gt; s{a};
</pre></blockquote>
<p>
The problem is that <tt>span</tt>'s constructors include
</p>
<ul>
<li><p>A constructor template that takes any <tt>Container</tt> that is neither a raw array nor a <tt>std::array</tt></p></li>
<li><p>A constructor template that takes an <tt>array&lt;value_type, N&gt;&amp;</tt></p></li>
<li><p>A constructor template that takes a <tt>const array&lt;value_type, N&gt;&amp;</tt></p></li>
</ul>
<p>
So the first is excluded, and the other two don't match. We can change the array constructor templates to take an
<tt>array&lt;T, N&gt;</tt> with the requirement that <tt>T(*)[]</tt> is convertible to <tt>ElementType(*)[]</tt>?
<p/>
<b>Jean Guegant:</b>
<p/>
It is impossible to create a <tt>std::span</tt> from a <tt>std::array&lt;const T, X&gt;</tt> given the current
set of constructors of <tt>std::span</tt> (22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a>):
</p>
<blockquote><pre>
std::array&lt;const int, 4&gt; a = {1, 2, 3, 4};
std::span&lt;const int&gt; s{a}; <i>// No overload can be found.</i>
std::span s{a}; <i>// CTAD doesn't help either.</i>
</pre></blockquote>
<p>
Both constructors accepting a <tt>std::array</tt> (22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> p11) require the first template
parameter of the <tt>std::array</tt> parameter to be <tt>value_type</tt>:
</p>
<blockquote><pre>
template&lt;size_t N&gt; constexpr span(array&lt;value_type, N&gt;&amp; arr) noexcept;
template&lt;size_t N&gt; constexpr span(const array&lt;value_type, N&gt;&amp; arr) noexcept;
</pre></blockquote>
<p>
<tt>value_type</tt> being defined as <tt>remove_cv_t&lt;ElementType&gt;</tt> &mdash; this constrains the first
template parameter not to be <tt>const</tt>.
<p/>
Both constructors accepting a generic <tt>Container</tt> (22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> p14) have a
constraint &mdash; (p14.3) <tt>Container</tt> is not a specialization of <tt>array</tt> &mdash;
rejecting <tt>std::array</tt>.
<p/>
While you can call <tt>std::array&lt;const T, X&gt;::data</tt> and <tt>std::array&lt;const T, X&gt;::size</tt>
to manually create a <tt>std::span</tt>, we should, in my opinion, offer a proper overload for this scenario.
Two reasons came to my mind:
</p>
<ol>
<li><p><tt>std::span</tt> handles C-arrays and <tt>std::arrays</tt> in an asymmetric way. The constructor
taking a C-array (22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> p11) is using <tt>element_type</tt> and as such can work with
<tt>const T</tt>:</p>
<blockquote><pre>
const int a[] = {1, 2, 3, 4};
std::span&lt;const int&gt; s{a}; <i>// It works</i>
</pre></blockquote>
<p>
If a user upgrades her/his code from C-arrays to a <tt>std::array</tt>s and literally take the type
<tt>const T</tt> and use it as the first parameter of <tt>std::array</tt>, he/she will face an error.
</p>
</li>
<li><p>Even if the user is aware that <tt>const std::array&lt;T, X&gt;</tt> is more idiomatic than
<tt>std::array&lt;const T, X&gt;</tt>, the second form may appear in the context of template
instantiation.</p></li>
</ol>
<p>
At the time this issue is written <tt>gls::span</tt>, from which <tt>std::span</tt> is partly based on,
does not suffer from the same issue: Its constructor taking a generic <tt>const Container&amp;</tt> does
not constraint the <tt>Container</tt> not to be a <tt>std::array</tt> (although its constructor taking
a generic <tt>Container&amp;</tt> does). For the users willing to upgrade from <tt>gsl::span</tt> to
<tt>std::span</tt>, this could be a breaking change.
</p>

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


<p><i>[2020-02-13 Tim updates PR]</i></p>

<p>
The previous PR's change to the raw array constructor is both 1) unnecessary and 2) incorrect; it prevents
<tt>span&lt;const int&gt;</tt> from being initialized with an <tt>int[42]</tt> xvalue.
</p>

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

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

<blockquote class="note">
<p>
The only change is to make the constructors templated on the element type of the array as well.
We already have the right constraints in place. It's just that the 2nd constraint is trivially
satisfied today by the raw array constructor and either always or never satisfied by the <tt>std::array</tt> one.
</p>
</blockquote>

<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>
template&lt;class ElementType, size_t Extent = dynamic_extent&gt;
class span {
public:
  [&hellip;]
  <i>// 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a>, constructors, copy, and assignment</i>
  constexpr span() noexcept;
  constexpr span(pointer ptr, index_type count);
  constexpr span(pointer first, pointer last);
  template&lt;<ins>class T,</ins> size_t N&gt;
    constexpr span(<ins>T</ins><del>element_type</del> (&amp;arr)[N]) noexcept;
  template&lt;<ins>class T,</ins> size_t N&gt;
    constexpr span(array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
  template&lt;<ins>class T,</ins> size_t N&gt;
    constexpr span(const array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
  [&hellip;]
};
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;<ins>class T,</ins> size_t N&gt;
  constexpr span(<ins>T</ins><del>element_type</del> (&amp;arr)[N]) noexcept;
template&lt;<ins>class T,</ins> size_t N&gt;
  constexpr span(array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
template&lt;<ins>class T,</ins> size_t N&gt;
  constexpr span(const array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
</pre>
<blockquote>
<p>
-11- <i>Constraints:</i>
</p>
<ol style="list-style-type: none">
<li><p>(11.1) &mdash; <tt>extent == dynamic_extent || N == extent</tt> is <tt>true</tt>, and</p></li>
<li><p>(11.2) &mdash; <tt>remove_pointer_t&lt;decltype(data(arr))&gt;(*)[]</tt> is convertible to <tt>ElementType(*)[]</tt>.</p></li>
</ol>
<p>
-12- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the supplied array.
<p/>
-13- <i>Ensures:</i> <tt>size() == N &amp;&amp; data() == data(arr)</tt> <ins>is <tt>true</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4849">N4849</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>
template&lt;class ElementType, size_t Extent = dynamic_extent&gt;
class span {
public:
  [&hellip;]
  <i>// 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a>, constructors, copy, and assignment</i>
  constexpr span() noexcept;
  [&hellip;]
  template&lt;size_t N&gt;
    constexpr span(element_type (&amp;arr)[N]) noexcept;
  template&lt;<ins>class T,</ins> size_t N&gt;
    constexpr span(array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
  template&lt;<ins>class T,</ins> size_t N&gt;
    constexpr span(const array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
  [&hellip;]
};
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;size_t N&gt;
  constexpr span(element_type (&amp;arr)[N]) noexcept;
template&lt;<ins>class T,</ins> size_t N&gt;
  constexpr span(array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
template&lt;<ins>class T,</ins> size_t N&gt;
  constexpr span(const array&lt;<ins>T</ins><del>value_type</del>, N&gt;&amp; arr) noexcept;
</pre>
<blockquote>
<p>
-11- <i>Constraints:</i>
</p>
<ol style="list-style-type: none">
<li><p>(11.1) &mdash; <tt>extent == dynamic_extent || N == extent</tt> is <tt>true</tt>, and</p></li>
<li><p>(11.2) &mdash; <tt>remove_pointer_t&lt;decltype(data(arr))&gt;(*)[]</tt> is convertible to <tt>ElementType(*)[]</tt>.</p></li>
</ol>
<p>
-12- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the supplied array.
<p/>
-13- <i>Postconditions:</i> <tt>size() == N &amp;&amp; data() == data(arr)</tt> <ins>is <tt>true</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3260" href="#3260">3260</a><sup><a href="https://cplusplus.github.io/LWG/issue3260">(i)</a></sup>. <tt>year_month*</tt> arithmetic rejects durations convertible to years</h3>
<p><b>Section:</b> 27.8 <a href="https://wg21.link/time.cal">[time.cal]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-08-15 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently, the <tt>year_month*</tt> types (<tt>year_month</tt>,
<tt>year_month_day</tt>) provide separate arithmetic operators with
duration type of <tt>years</tt> or <tt>months</tt>. This is an intentional
optimization that avoids performing modulo arithmetic in the former case.
<p/>
However, these make the arithmetic of <code>year_month*</code> types
with durations that are convertible to <code>years</code> (and by
consequence to <code>months</code>) ambiguous. For example, the following
code is ambiguous:
</p>
<blockquote>
<pre>
using decades = duration&lt;int, ratio_multiply&lt;ratio&lt;10&gt;, years::period&gt;&gt;;
auto ymd = 2001y/January/1d;
ymd += decades(1); // <span style="color:#C80000;font-weight:bold">error, ambiguous</span>
</pre>
</blockquote>
<p>
while less usual durations that are only convertible to <tt>months</tt> work correctly:
</p>
<blockquote>
<pre>
using decamonths = duration&lt;int, ratio_multiply&lt;ratio&lt;10&gt;, months::period&gt;&gt;;
auto ymd = 2001y/January/1d;
ymd += decamonths(1);
</pre>
</blockquote>
<p>
The example implementation resolves the issues by making sure that the
<tt>years</tt> overload will be preferred in case of ambiguity, by declaring the
<tt>months</tt> overload a function template with a default argument for its parameter
(suggested by Tim Song):
</p>
<blockquote>
<pre>
<ins>template&lt;class = <em>unspecified</em>&gt;</ins>
constexpr year_month_weekday&amp; operator+=(const months&amp; m) noexcept;
constexpr year_month_weekday&amp; operator+=(const years&amp; m) noexcept;
</pre>
</blockquote>

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


<p><i>[2019-09-14; Tomasz and Howard provide concrete wording]</i></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>

<blockquote class="note">
<p>
[<i>Drafting note:</i> Suggested wording below assumes that we can add a <i>Constraints:</i> to a 
signature where the constraint does not apply to a deduced template. We have examples of such 
constraints in other parts of the WD (e.g. 20.11.1.2.1 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a>/p15, 
20.11.1.2.3 <a href="https://wg21.link/unique.ptr.single.asgn">[unique.ptr.single.asgn]</a>/p1). And we have the old form "does not participate &hellip;" 
being used for non-deduced templates in several places as well (e.g. 20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>/p5).
<p/>
There are several ways of implementing such a constraint, such as adding a gratuitous template 
parameter.]
</p>
</blockquote>

<ol>
<li><p>Modify 27.8.13.2 <a href="https://wg21.link/time.cal.ym.members">[time.cal.ym.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month&amp; operator+=(const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this + dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month&amp; operator-=(const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-6- <i>Effects:</i> <tt>*this = *this - dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.13.3 <a href="https://wg21.link/time.cal.ym.nonmembers">[time.cal.ym.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month operator+(const year_month&amp; ym, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-3- <i>Returns:</i> A <tt>year_month</tt> value <tt>z</tt> such that <tt>z - ym == dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month operator+(const months&amp; dm, const year_month&amp; ym) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-5- <i>Returns:</i> <tt>ym + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month operator-(const year_month&amp; ym, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-6- <i>Returns:</i> <tt>ym + -dm</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.14.2 <a href="https://wg21.link/time.cal.ymd.members">[time.cal.ymd.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-7- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-9- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.14.3 <a href="https://wg21.link/time.cal.ymd.nonmembers">[time.cal.ymd.nonmembers]</a> as indicated:</p>
<blockquote>
<pre>
constexpr year_month_day operator+(const year_month_day&amp; ymd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-3- <i>Returns:</i> <tt>(ymd.year() / ymd.month() + dm) / ymd.day()</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day operator+(const months&amp; dm, const year_month_day&amp; ymd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-5- <i>Returns:</i> <tt>ymd + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day operator+(const months&amp; dm, const year_month_day&amp; ymd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-6- <i>Returns:</i> <tt>ymd + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.15.2 <a href="https://wg21.link/time.cal.ymdlast.members">[time.cal.ymdlast.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day_last&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-2- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day_last&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.15.3 <a href="https://wg21.link/time.cal.ymdlast.nonmembers">[time.cal.ymdlast.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day_last
  operator+(const year_month_day_last&amp; ymdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-3- <i>Returns:</i> <tt>(ymdl.year() / ymdl.month() + dm) / last</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day_last
  operator+(const months&amp; dm, const year_month_day_last&amp; ymdl) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Returns:</i> <tt>ymdl + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day_last
  operator-(const year_month_day_last&amp; ymdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-5- <i>Returns:</i> <tt>ymdl + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.16.2 <a href="https://wg21.link/time.cal.ymwd.members">[time.cal.ymwd.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-6- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_weekday&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-8- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.16.3 <a href="https://wg21.link/time.cal.ymwd.nonmembers">[time.cal.ymwd.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday operator+(const year_month_weekday&amp; ymwd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-2- <i>Returns:</i> <tt>(ymwd.year() / ymwd.month() + dm) / ymwd.weekday_indexed()</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday operator+(const months&amp; dm, const year_month_weekday&amp; ymwd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-3- <i>Returns:</i> <tt>ymwd + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday operator-(const year_month_weekday&amp; ymwd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Returns:</i> <tt>ymwd + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.17.2 <a href="https://wg21.link/time.cal.ymwdlast.members">[time.cal.ymwdlast.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday_last&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-2- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.17.3 <a href="https://wg21.link/time.cal.ymwdlast.nonmembers">[time.cal.ymwdlast.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday_last
  operator+(const year_month_weekday_last&amp; ymwdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-2- <i>Returns:</i> <tt>(ymwdl.year() / ymwdl.month() + dm) / ymwdl.weekday_last()</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last
  operator+(const months&amp; dm, const year_month_weekday_last&amp; ymwdl) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-3- <i>Returns:</i> <tt>ymwdl + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last
  operator-(const year_month_weekday_last&amp; ymwdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> The argument supplied by the caller for the <tt>months</tt> 
parameter is not implicitly convertible to <tt>years</tt>.</ins>
<p/>
-4- <i>Returns:</i> <tt>ymwdl + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Tim Song found a wording problem that we would like to resolve:
<p/>
Given a class like
</p>
<blockquote><pre>
struct C : months {
  operator years();
};
</pre></blockquote>
<p>
The previous wording requires calls with a <tt>C</tt> argument to use the <tt>years</tt> overload, which 
would require implementation heroics since its conversion sequence to <tt>months</tt> is better than <tt>years</tt>.
</p>

<p><i>[2020-02 Status to Immediate on Friday morning in Prague.]</i></p>



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

<blockquote class="note">
<p>
[<i>Drafting note:</i> Suggested wording below assumes that we can add a <i>Constraints:</i> to a 
signature where the constraint does not apply to a deduced template. We have examples of such 
constraints in other parts of the WD (e.g. 20.11.1.2.1 <a href="https://wg21.link/unique.ptr.single.ctor">[unique.ptr.single.ctor]</a>/p15, 
20.11.1.2.3 <a href="https://wg21.link/unique.ptr.single.asgn">[unique.ptr.single.asgn]</a>/p1). And we have the old form "does not participate &hellip;" 
being used for non-deduced templates in several places as well (e.g. 20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>/p5).
<p/>
There are several ways of implementing such a constraint, such as adding a gratuitous template 
parameter.]
</p>
</blockquote>

<ol>
<li><p>Modify 27.8.13.2 <a href="https://wg21.link/time.cal.ym.members">[time.cal.ym.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month&amp; operator+=(const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this + dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month&amp; operator-=(const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-6- <i>Effects:</i> <tt>*this = *this - dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.13.3 <a href="https://wg21.link/time.cal.ym.nonmembers">[time.cal.ym.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month operator+(const year_month&amp; ym, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-3- <i>Returns:</i> A <tt>year_month</tt> value <tt>z</tt> such that <tt>z - ym == dm</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month operator+(const months&amp; dm, const year_month&amp; ym) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-5- <i>Returns:</i> <tt>ym + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month operator-(const year_month&amp; ym, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-6- <i>Returns:</i> <tt>ym + -dm</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.14.2 <a href="https://wg21.link/time.cal.ymd.members">[time.cal.ymd.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-7- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-9- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.14.3 <a href="https://wg21.link/time.cal.ymd.nonmembers">[time.cal.ymd.nonmembers]</a> as indicated:</p>
<blockquote>
<pre>
constexpr year_month_day operator+(const year_month_day&amp; ymd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-3- <i>Returns:</i> <tt>(ymd.year() / ymd.month() + dm) / ymd.day()</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day operator+(const months&amp; dm, const year_month_day&amp; ymd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-5- <i>Returns:</i> <tt>ymd + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day operator+(const months&amp; dm, const year_month_day&amp; ymd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-6- <i>Returns:</i> <tt>ymd + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.15.2 <a href="https://wg21.link/time.cal.ymdlast.members">[time.cal.ymdlast.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day_last&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-2- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_day_last&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.15.3 <a href="https://wg21.link/time.cal.ymdlast.nonmembers">[time.cal.ymdlast.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_day_last
  operator+(const year_month_day_last&amp; ymdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-3- <i>Returns:</i> <tt>(ymdl.year() / ymdl.month() + dm) / last</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day_last
  operator+(const months&amp; dm, const year_month_day_last&amp; ymdl) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Returns:</i> <tt>ymdl + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_day_last
  operator-(const year_month_day_last&amp; ymdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-5- <i>Returns:</i> <tt>ymdl + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.16.2 <a href="https://wg21.link/time.cal.ymwd.members">[time.cal.ymwd.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-6- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_weekday&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-8- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.16.3 <a href="https://wg21.link/time.cal.ymwd.nonmembers">[time.cal.ymwd.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday operator+(const year_month_weekday&amp; ymwd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-2- <i>Returns:</i> <tt>(ymwd.year() / ymwd.month() + dm) / ymwd.weekday_indexed()</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday operator+(const months&amp; dm, const year_month_weekday&amp; ymwd) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-3- <i>Returns:</i> <tt>ymwd + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday operator-(const year_month_weekday&amp; ymwd, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Returns:</i> <tt>ymwd + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.17.2 <a href="https://wg21.link/time.cal.ymwdlast.members">[time.cal.ymwdlast.members]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday_last&amp; operator+=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-2- <i>Effects:</i> <tt>*this = *this + m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last&amp; operator-=(const months&amp; m) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Effects:</i> <tt>*this = *this - m</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 27.8.17.3 <a href="https://wg21.link/time.cal.ymwdlast.nonmembers">[time.cal.ymwdlast.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
constexpr year_month_weekday_last
  operator+(const year_month_weekday_last&amp; ymwdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-2- <i>Returns:</i> <tt>(ymwdl.year() / ymwdl.month() + dm) / ymwdl.weekday_last()</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last
  operator+(const months&amp; dm, const year_month_weekday_last&amp; ymwdl) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-3- <i>Returns:</i> <tt>ymwdl + dm</tt>.
</p>
</blockquote>
<pre>
constexpr year_month_weekday_last
  operator-(const year_month_weekday_last&amp; ymwdl, const months&amp; dm) noexcept;
</pre>
<blockquote>
<p>
<ins>-?- <i>Constraints:</i> If the argument supplied by the caller for the <tt>months</tt> 
parameter is convertible to <tt>years</tt>, its implicit conversion sequence to <tt>years</tt> is 
worse than its implicit conversion sequence to <tt>months</tt> (12.4.3.2 <a href="https://wg21.link/over.ics.rank">[over.ics.rank]</a>).</ins>
<p/>
-4- <i>Returns:</i> <tt>ymwdl + (-dm)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3262" href="#3262">3262</a><sup><a href="https://cplusplus.github.io/LWG/issue3262">(i)</a></sup>. Formatting of negative durations is not specified</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#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-08-18 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification of the formatting for <code>std::chrono::duration</code> and 
<code>std::hh_mm_ss</code> types is unclear in regards the the handling of negative values. 
To illustrate:
</p>
<blockquote><pre>
std::cout &lt;&lt; std::format("%H:%M:%S", -10'000s); <i>// prints either -02:46:40 or -02:-46:-40</i>
</pre></blockquote>
<p>
The indented behavior (and currently implemented, see 
<a href="https://wandbox.org/permlink/mrw03IaAldP7Bdx1">here</a>) is to apply the
sign once, before the leftmost converted field.
</p>

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


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

<blockquote class="note">
<p>
[<i>Drafting note:</i> With the above clarification, the specification of the
<code>operator&lt;&lt;</code> for <code>hh_mm_ss</code> may be simplified to
<code>format("{:%T}", hms)</code>.]
</p>
</blockquote>

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

<blockquote>
<p>
-2- Each conversion specifier <i>conversion-spec</i> is replaced by appropriate 
characters as described in Table [tab:time.format.spec]. Some of the conversion 
specifiers depend on the locale that is passed to the formatting function if 
the latter takes one, or the global locale otherwise. If the formatted object 
does not contain the information the conversion specifier refers to, an 
exception of type <tt>format_error</tt> is thrown.
<p/>
<ins>-?- The result of formatting a <tt>std::chrono::duration</tt> instance holding 
a negative value, or of an <tt>hh_mm_ss</tt> object <tt>h</tt> for which <tt>h.is_negative()</tt> 
is <tt>true</tt>, is equivalent to the output of the corresponding positive value, 
with a <tt>-</tt> character placed before the replacement of the leftmost conversion
specifier.</ins>
<p/>
<ins>[<i>Example:</i></ins>
</p>
<blockquote><pre>
<ins>cout &lt;&lt; format("%T", -10'000s); <i>// prints:</i> -02:46:40
cout &lt;&lt; format("%H:%M:%S", -10'000s); <i>// prints:</i> -02:46:40
cout &lt;&lt; format("minutes %M, hours %H, seconds %S", -10'000s); <i>// prints:</i> minutes -46, hours 02, seconds 40</ins>
</pre></blockquote>
<p>
<ins>&mdash; <i>end example</i>]</ins>
<p/>
-3- Unless explicitly requested, [&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 27.9.3 <a href="https://wg21.link/time.hms.nonmembers">[time.hms.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Duration&gt;
basic_ostream&lt;charT, traits&gt;&amp;
operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const hh_mm_ss&lt;Duration&gt;&amp; hms);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return os &lt;&lt; format(os.getloc(),
             <del>hms.is_negative() ? <i>STATICALLY-WIDEN</i>&lt;charT&gt;("-{:%T}")
                               : </del><i>STATICALLY-WIDEN</i>&lt;charT&gt;("{:%T}"),
             <del>abs(</del>hms<del>.to_duration())</del>);
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2019-09-14; Howard improves wording]</i></p>

<p><i>[2020-02; Status set to Immediate after LWG discussion Thursday in Prague. (Minor example wording cleanup)]</i></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> With the above clarification, the specification of the
<code>operator&lt;&lt;</code> for <code>hh_mm_ss</code> may be simplified to
<code>format("{:%T}", hms)</code>.]
</p>
</blockquote>

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

<blockquote>
<p>
-2- Each conversion specifier <i>conversion-spec</i> is replaced by appropriate 
characters as described in Table [tab:time.format.spec]. Some of the conversion 
specifiers depend on the locale that is passed to the formatting function if 
the latter takes one, or the global locale otherwise. If the formatted object 
does not contain the information the conversion specifier refers to, an 
exception of type <tt>format_error</tt> is thrown.
<p/>
<ins>-?- The result of formatting a <tt>std::chrono::duration</tt> instance holding 
a negative value, or of an <tt>hh_mm_ss</tt> object <tt>h</tt> for which <tt>h.is_negative()</tt> 
is <tt>true</tt>, is equivalent to the output of the corresponding positive value, 
with a <tt><i>STATICALLY-WIDEN</i>&lt;charT&gt;("-")</tt> character sequence placed 
before the replacement of the leftmost conversion specifier.</ins>
<p/>
<ins>[<i>Example:</i></ins>
</p>
<blockquote><pre>
<ins>cout &lt;&lt; format("{%:T}", -10'000s); <i>// prints:</i> -02:46:40
cout &lt;&lt; format("{:%H:%M:%S}", -10'000s); <i>// prints:</i> -02:46:40
cout &lt;&lt; format("{:minutes %M, hours %H, seconds %S}", -10'000s); <i>// prints:</i> minutes -46, hours 02, seconds 40</ins>
</pre></blockquote>
<p>
<ins>&mdash; <i>end example</i>]</ins>
<p/>
-3- Unless explicitly requested, [&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 27.9.3 <a href="https://wg21.link/time.hms.nonmembers">[time.hms.nonmembers]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Duration&gt;
basic_ostream&lt;charT, traits&gt;&amp;
operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const hh_mm_ss&lt;Duration&gt;&amp; hms);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
return os &lt;&lt; format(os.getloc(),
             <del>hms.is_negative() ? <i>STATICALLY-WIDEN</i>&lt;charT&gt;("-{:%T}")
                               : </del><i>STATICALLY-WIDEN</i>&lt;charT&gt;("{:%T}"),
             <del>abs(</del>hms<del>.to_duration())</del>);
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>



<hr>
<h3><a name="3269" href="#3269">3269</a><sup><a href="https://cplusplus.github.io/LWG/issue3269">(i)</a></sup>. Parse manipulators do not specify the result of the extraction from stream</h3>
<p><b>Section:</b> 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-09-01 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.parse">active issues</a> in [time.parse].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.parse">issues</a> in [time.parse].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
None of the <tt>parse</tt> manipulators for the <tt>chrono</tt> types
specifies the result of the extraction from the stream, as consequence 
they cannot be chained with the other read operations (at least portably). 
For example the following code is not required to work:
</p>
<blockquote>
<pre>
std::chrono::sys_stime s; 
int x;
std::cin &gt;&gt; std::chrono::parse("%X", s) &gt;&gt; x;
</pre>
</blockquote>

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


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

<blockquote class="note">
<p>
[<i>Drafting note:</i> As a drive-by fix the <i>Remarks</i> element is also 
converted to a <i>Constraints</i> element. The wording integrates the resolution for 
LWG <a href="lwg-defects.html#3235">3235</a>.
</p>
</blockquote>

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

<blockquote>
<p>
-1- Each parse overload specified in this subclause calls <tt>from_stream</tt> unqualified, 
so as to enable argument dependent lookup (6.5.2 <a href="https://wg21.link/basic.lookup.argdep">[basic.lookup.argdep]</a>). 
<ins>In the following paragraphs, let <tt>is</tt> denote an object of type 
<tt>basic_istream&lt;charT, traits&gt;</tt> and let <tt>I</tt> be
<tt>basic_istream&lt;charT, traits&gt;&amp;</tt>, where <tt>charT</tt> and
<tt>traits</tt> are template parameters in that context.</ins>
</p>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp);
</pre>
<blockquote>
<p>
-2- <i><del>Remarks</del><ins>Constraints</ins>:</i> <del>This function shall not participate in 
overload resolution unless</del><ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), fmt.c_str(), tp)
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-3- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression
<tt>is &gt;&gt; parse(fmt, tp)</tt> has type <tt>I</tt>, value <tt>is</tt>, 
and</ins> calls <tt>from_stream(is, fmt.c_str(), tp)</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          basic_string&lt;charT, traits, Alloc&gt;&amp; abbrev);
</pre>
<blockquote>
<p>
-4- <i><del>Remarks</del><ins>Constraints</ins>:</i> <del>This function shall not participate 
in overload resolution unless</del><ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), fmt.c_str(), tp, addressof(abbrev))
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-5- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, abbrev)</tt> has type <tt>I</tt>, value <tt>is</tt>, and</ins> calls 
<tt>from_stream(is, fmt.c_str(), tp, addressof(abbrev))</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          minutes&amp; offset);
</pre>
<blockquote>
<p>
-6- <i><del>Remarks</del><ins>Constraints</ins>:</i> <del>This function shall not participate 
in overload resolution unless</del><ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), fmt.c_str(), tp, 
            <ins>declval&lt;basic_string&lt;charT, traits, Alloc&gt;*&gt;()</ins><del>nullptr</del>, &amp;offset)
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-7- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, offset)</tt> has type <tt>I</tt>, value <tt>is</tt>, and</ins> 
calls <tt>from_stream(is, fmt.c_str(), tp, <ins>static_cast&lt;basic_string&lt;charT, 
traits, Alloc&gt;*&gt;(</ins>nullptr<ins>)</ins>, &amp;offset)</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable>
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          basic_string&lt;charT, traits, Alloc&gt;&amp; abbrev, minutes&amp; offset);
</pre>
<blockquote>
<p>
-8- <i><del>Remarks</del><ins>Constraints</ins>:</i> <del>This function shall not participate 
in overload resolution unless</del><ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(),
            fmt.c_str(), tp, addressof(abbrev), &amp;offset)
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-9- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, abbrev, offset)</tt> has type <tt>I</tt>, value <tt>is</tt>, 
and</ins> calls <tt>from_stream(is, fmt.c_str(), tp, addressof(abbrev), &amp;offset)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Issue wording has been rebased.
</p>
<p><i>[2020-02 Status to Immediate on Friday morning in Prague.]</i></p>



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

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

<blockquote>
<p>
-1- Each <tt>parse</tt> overload specified in this subclause calls <tt>from_stream</tt> unqualified, 
so as to enable argument dependent lookup (6.5.2 <a href="https://wg21.link/basic.lookup.argdep">[basic.lookup.argdep]</a>). In the following paragraphs, 
let <tt>is</tt> denote an object of type <tt>basic_istream&lt;charT, traits&gt;</tt> <ins>and let <tt>I</tt> be 
<tt>basic_istream&lt;charT, traits&gt;&amp;</tt></ins>, where <tt>charT</tt> and <tt>traits</tt> are 
template parameters in that context.
</p>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp);
</pre>
<blockquote>
<p>
-2- <i>Constraints:</i> <ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), fmt.c_str(), tp)
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-3- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression
<tt>is &gt;&gt; parse(fmt, tp)</tt> has type <tt>I</tt>, value <tt>is</tt>, 
and</ins> calls <tt>from_stream(is, fmt.c_str(), tp)</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          basic_string&lt;charT, traits, Alloc&gt;&amp; abbrev);
</pre>
<blockquote>
<p>
-4- <i>Constraints:</i> <ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), fmt.c_str(), tp, addressof(abbrev))
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-5- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, abbrev)</tt> has type <tt>I</tt>, value <tt>is</tt>, and</ins> calls 
<tt>from_stream(is, fmt.c_str(), tp, addressof(abbrev))</tt>.
</p>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable&gt;
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          minutes&amp; offset);
</pre>
<blockquote>
<p>
-6- <i>Constraints:</i> The expression
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(), 
            fmt.c_str(), tp, 
            declval&lt;basic_string&lt;charT, traits, Alloc&gt;*&gt;(), 
            &amp;offset)
</pre></blockquote>
is well-formed when treated as an unevaluated operand.
<p/>
-7- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, offset)</tt> has type <tt>I</tt>, value <tt>is</tt>, and</ins> 
calls
</p>
<blockquote><pre>
from_stream(is, 
            fmt.c_str(), tp, 
            static_cast&lt;basic_string&lt;charT, traits, Alloc&gt;*&gt;(nullptr), 
            &amp;offset)
</pre></blockquote>
</blockquote>
<pre>
template&lt;class charT, class traits, class Alloc, class Parsable>
  <i>unspecified</i>
    parse(const basic_string&lt;charT, traits, Alloc&gt;&amp; fmt, Parsable&amp; tp,
          basic_string&lt;charT, traits, Alloc&gt;&amp; abbrev, minutes&amp; offset);
</pre>
<blockquote>
<p>
-8- <i>Constraints:</i> <ins>The expression</ins>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;&amp;&gt;(),
            fmt.c_str(), tp, addressof(abbrev), &amp;offset)
</pre></blockquote>
is <del>a valid expression</del><ins>well-formed when treated as an unevaluated operand</ins>.
<p/>
-9- <i>Returns:</i> A manipulator <ins>such</ins> that<del>, when extracted from a 
<tt>basic_istream&lt;charT, traits&gt; is</tt>,</del><ins>the expression <tt>is &gt;&gt; 
parse(fmt, tp, abbrev, offset)</tt> has type <tt>I</tt>, value <tt>is</tt>, 
and</ins> calls <tt>from_stream(is, fmt.c_str(), tp, addressof(abbrev), &amp;offset)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3270" href="#3270">3270</a><sup><a href="https://cplusplus.github.io/LWG/issue3270">(i)</a></sup>. Parsing and formatting <tt>%j</tt> with <tt>duration</tt>s</h3>
<p><b>Section:</b> 27.12 <a href="https://wg21.link/time.format">[time.format]</a>, 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2019-09-02 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>%j</tt> represents the day number of the year when formatting and parsing <tt>time_point</tt>s. 
It is also handy to interpret this flag consistently when formatting and parsing durations. That 
is if there is not enough information in the stream to represent a <tt>time_point</tt>, and if the 
target of the format/parse is a <tt>duration</tt>, <tt>%j</tt> represents a number of days.
</p>
<blockquote>
<pre>
#include &lt;chrono&gt;
#include &lt;iostream&gt;
#include &lt;sstream&gt;
#include &lt;string&gt;

int main()
{
  using namespace std;
  using namespace std::chrono;
  <i>// Parse %j as number of days into a duration</i>
  istringstream in{"222"};
  hours d;
  in &gt;&gt; parse("%j", d);
  cout &lt;&lt; d &lt;&lt; '\n';
  cout &lt;&lt; format("{:%j}", d) &lt;&lt; '\n';
}
</pre>
</blockquote>
<p>
Output:
</p>
<blockquote>
<pre>
5328h
222
</pre>
</blockquote>
<p><i>[2019-10 Priority set to 2 after reflector discussion]</i></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 "Table 98 &mdash; Meaning of conversion specifiers"
 [tab:time.format.spec] as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 98 &mdash; Meaning of conversion specifiers  [tab:time.format.spec]</caption>
<tr style="text-align:center">
<th>Specifier</th>
<th>Replacement</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td><tt>%j</tt></td>
<td>The day of the year as a decimal number. Jan 1 is <tt>001</tt>. If the result is less than three<br/>
digits, it is left-padded with <tt>0</tt> to three digits. <ins>If the type being formatted is a<br/> 
specialization of <tt>duration</tt>, it is formatted as a decimal number of <tt>days</tt>.</ins></td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>

</li>

<li><p>Modify "Table 99 &mdash; Meaning of <tt>parse</tt> flags"
 [tab:time.parse.spec] as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 99 &mdash; Meaning of <tt>parse</tt> flags  [tab:time.parse.spec]</caption>
<tr style="text-align:center">
<th>Flag</th>
<th>Parsed value</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td><tt>%j</tt></td>
<td>The day of the year as a decimal number. Jan 1 is <tt>1</tt>. The modified command <tt>%<i>N</i>j</tt><br/>
specifies the maximum number of characters to read. If <tt><i>N</i></tt> is not specified, the default<br/>
is <tt>3</tt>. Leading zeroes are permitted but not required. <ins>If the type being parsed is a<br/> 
specialization of <tt>duration</tt>, it is parsed as a decimal number of <tt>days</tt>.</ins></td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>

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

<p><i>[2020-02-13 After Thursday afternoon discussion in Prague, Marshall provides updated wording.]</i></p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</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 "Table 98 &mdash; Meaning of conversion specifiers"
 [tab:time.format.spec] as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 98 &mdash; Meaning of conversion specifiers  [tab:time.format.spec]</caption>
<tr style="text-align:center">
<th>Specifier</th>
<th>Replacement</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td><tt>%j</tt></td>
<td><ins>If the type being formatted is a specialization of <tt>duration</tt>, 
the decimal number of <tt>days</tt><br/>without padding. Otherwise, the</ins><del>The</del> 
day of the year as a decimal number.<br/>Jan 1 is <tt>001</tt>. If the result 
is less than three digits, it is left-padded with <tt>0</tt> to three digits. </td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>

</li>

<li><p>Modify "Table 99 &mdash; Meaning of <tt>parse</tt> flags"
 [tab:time.parse.spec] as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 99 &mdash; Meaning of <tt>parse</tt> flags  [tab:time.parse.spec]</caption>
<tr style="text-align:center">
<th>Flag</th>
<th>Parsed value</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td><tt>%j</tt></td>
<td><ins>If the type being parsed is a specialization of <tt>duration</tt>,<br/>
a decimal number of <tt>days</tt>. Otherwise, the</ins><del>The</del> 
day of the year as a decimal number. Jan 1 is <tt>1</tt>.<br/>
<ins>In either case, the</ins><del>The</del> modified command <tt>%<i>N</i>j</tt> specifies the maximum number of characters to read.<br/>
If <tt><i>N</i></tt> is not specified, the default is <tt>3</tt>. Leading zeroes are permitted but not required.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>

</li>
</ol>





<hr>
<h3><a name="3282" href="#3282">3282</a><sup><a href="https://cplusplus.github.io/LWG/issue3282">(i)</a></sup>. <tt>subrange</tt> converting constructor should disallow derived to base conversions</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#Immediate">Immediate</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-10 <b>Last modified:</b> 2020-02-10</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code leads to slicing and general badness:
</p>
<blockquote><pre>
struct Base {};
struct Derived : Base {};
subrange&lt;Derived*&gt; sd;
subrange&lt;Base*&gt; sb = sd;
</pre></blockquote>
<p>
Traversal operations on iterators that are pointers do pointer arithmetic. If a <tt>Base*</tt> is 
actually pointing to a <tt>Derived*</tt>, then pointer arithmetic is invalid. <tt>subrange</tt>'s 
constructors can easily flag this invalid code, and probably should.
<p/>
The following PR incorporates the suggested fix to issue LWG <a href="lwg-active.html#3281">3281</a> I previously reported.
<p/>
Suggested priority: P1, since it will be hard to fix this after C++20 ships.
</p>
<p><i>[2019-10 Priority set to 1 and status to LEWG after reflector discussion]</i></p>

<p><i>[2019-10; Marshall comments]</i></p>

<p>
This issue would resolve <a href="https://github.com/cplusplus/nbballot/issues/281">US-285</a>.
</p>
<p><i>[2019-11 LEWG says OK; Status to Open. Friday PM discussion in Belfast. Casey to investigate and report back.]</i></p>


<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to <a href="https://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 {
  <ins>template&lt;class From, class To&gt;
    concept <i>convertible-to-non-slicing</i> = <i>// exposition only</i>
      convertible_to&lt;From, To&gt; &amp;&amp;
      !(is_pointer_v&lt;decay_t&lt;From&gt;&gt; &amp;&amp;
      is_pointer_v&lt;decay_t&lt;To&gt;&gt; &amp;&amp;
      <i>not-same-as</i>&lt;remove_pointer_t&lt;decay_t&lt;From&gt;&gt;, remove_pointer_t&lt;decay_t&lt;To&gt;&gt;&gt;);</ins>
      
  template&lt;class T&gt;
    concept <i>pair-like</i> = <i>// exposition only</i>
      [&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>
      
   template&lt;class T, class U, class V&gt;
     concept <i>pair-like-convertible-from</i> = <i>// exposition only</i>
       !range&lt;T&gt; &amp;&amp; <i>pair-like</i>&lt;T&gt; &amp;&amp; 
       constructible_from&lt;T, U, V&gt; <ins>&amp;&amp;
       <i>convertible-to-non-slicing</i>&lt;U, tuple_element_t&lt;0, T&gt;&gt; &amp;&amp;
       convertible_to&lt;V, tuple_element_t&lt;1, T&gt;&gt;</ins>;

[&hellip;]
[&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:
    subrange() = default;
    
    constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s) requires (!StoreSize);
    
    constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s, 
                       <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n) requires (K == subrange_kind::sized);
    
    template&lt;<i>not-same-as</i>&lt;subrange&gt; R&gt;
      requires <i>forwarding-range</i>&lt;R&gt; &amp;&amp;
        <del>convertible_to</del><ins><i>convertible-to-non-slicing</i></ins>&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;);
    
    template&lt;<i>forwarding-range</i> R&gt;
      requires 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, <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n)
      requires (K == subrange_kind::sized)
        : subrange{ranges::begin(r), ranges::end(r), n}
    {}
    
    <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;]
  };
  
  <ins>template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  subrange(I, S) -&gt; subrange&lt;I, S&gt;;</ins>  
  
  [&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>
constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s) requires (!StoreSize);
</pre>
<blockquote>
<p>
-1- <i>Expects:</i> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s, 
                   <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n) requires (K == subrange_kind::sized);
</pre>
<blockquote>
<p>
-2- <i>Expects:</i> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;<i>not-same-as</i>&lt;subrange&gt; R&gt;
  requires <i>forwarding-range</i>&lt;R&gt; &amp;&amp;
    <del>convertible_to</del><ins><i>convertible-to-non-slicing</i></ins>&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> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-10; Prague]</i></p>

<p>
The group identified minor problems that have been fixed in the revised wording.
</p>

<p><i>[2020-02-10 Move to Immediate Monday afternoon in Prague]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://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 {
  <ins>template&lt;class From, class To&gt;
    concept <i>convertible-to-non-slicing</i> = <i>// exposition only</i>
      convertible_to&lt;From, To&gt; &amp;&amp;
      !(is_pointer_v&lt;decay_t&lt;From&gt;&gt; &amp;&amp;
      is_pointer_v&lt;decay_t&lt;To&gt;&gt; &amp;&amp;
      <i>not-same-as</i>&lt;remove_pointer_t&lt;decay_t&lt;From&gt;&gt;, remove_pointer_t&lt;decay_t&lt;To&gt;&gt;&gt;);</ins>
      
  template&lt;class T&gt;
    concept <i>pair-like</i> = <i>// exposition only</i>
      [&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>
      
   template&lt;class T, class U, class V&gt;
     concept <i>pair-like-convertible-from</i> = <i>// exposition only</i>
       !range&lt;T&gt; &amp;&amp; <i>pair-like</i>&lt;T&gt; &amp;&amp; 
       constructible_from&lt;T, U, V&gt; <ins>&amp;&amp;
       <i>convertible-to-non-slicing</i>&lt;U, tuple_element_t&lt;0, T&gt;&gt; &amp;&amp;
       convertible_to&lt;V, tuple_element_t&lt;1, T&gt;&gt;</ins>;

[&hellip;]
[&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:
    subrange() = default;
    
    constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s) requires (!StoreSize);
    
    constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s, 
                       <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n) requires (K == subrange_kind::sized);
    
    template&lt;<i>not-same-as</i>&lt;subrange&gt; R&gt;
      requires <i>forwarding-range</i>&lt;R&gt; &amp;&amp;
        <del>convertible_to</del><ins><i>convertible-to-non-slicing</i></ins>&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;);
    
    template&lt;<i>forwarding-range</i> R&gt;
      requires <del>convertible_to</del><ins><i>convertible-to-non-slicing</i></ins>&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, <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n)
      requires (K == subrange_kind::sized)
        : subrange{ranges::begin(r), ranges::end(r), n}
    {}
    
    <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;]
  };
  
  <ins>template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
  subrange(I, S) -&gt; subrange&lt;I, S&gt;;</ins>  
  
  [&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>
constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s) requires (!StoreSize);
</pre>
<blockquote>
<p>
-1- <i>Expects:</i> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
constexpr subrange(<ins><i>convertible-to-non-slicing</i>&lt;</ins>I<ins>&gt; auto</ins> i, S s, 
                   <i>make-unsigned-like-t</i>(iter_difference_t&lt;I&gt;) n) requires (K == subrange_kind::sized);
</pre>
<blockquote>
<p>
-2- <i>Expects:</i> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;<i>not-same-as</i>&lt;subrange&gt; R&gt;
  requires <i>forwarding-range</i>&lt;R&gt; &amp;&amp;
    <del>convertible_to</del><ins><i>convertible-to-non-slicing</i></ins>&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> [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3301" href="#3301">3301</a><sup><a href="https://cplusplus.github.io/LWG/issue3301">(i)</a></sup>. <tt>transform_view::iterator</tt> has incorrect <tt>iterator_category</tt></h3>
<p><b>Section:</b> 24.7.5.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Michel Morin <b>Opened:</b> 2019-10-03 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When the transformation function returns an rvalue, <tt>transform_view::iterator</tt> 
cannot model <tt><i>cpp17-forward-iterator</i></tt>. However, similar to LWG <a href="lwg-active.html#3291">3291</a>,
the current wording on <tt>transform_view::iterator::iterator_category</tt> does not 
consider this.
<p/>
As Casey Carter pointed out <a href="https://github.com/ericniebler/stl2/issues/637#issuecomment-535594100">here</a>,
the proposed wording below does not consider <tt>input_iterator</tt> that is not 
<tt><i>cpp17-input-iterator</i></tt> (this problem is not specific to the PR; it's pervasive 
in adapted iterators) and concepts-based determination would be a better fix for issues around 
<tt>iterator_category</tt>. But anyway, I consider this PR as a minimal fix at the moment.
</p>

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

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

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

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

<blockquote>
<p>
-2- <ins><tt>iterator::iterator_category</tt> is defined as follows:</ins> 
Let <tt>C</tt> denote the type <tt>iterator_traits&lt;iterator_t&lt;Base&gt;&gt;::iterator_category</tt>.
</p>
<ol style="list-style-type: none">
<li><p><ins>(2.?) &mdash; If <tt>is_lvalue_reference_v&lt;iter_reference_t&lt;iterator_t&lt;Base&gt;&gt;&gt;</tt> 
is <tt>true</tt>,</ins></p>
<ol style="list-style-type: none">
<li><p><ins>(2.?.?) &mdash;</ins> If <tt>C</tt> models <tt>derived_from&lt;contiguous_iterator_tag&gt;</tt>, 
then <tt>iterator_category</tt> denotes <tt>random_access_iterator_tag</tt>;</p></li>
<li><p><ins>(2.?.?) &mdash;</ins> <ins>O</ins><del>o</del>therwise, <tt>iterator_category</tt> denotes 
<tt>C</tt>.</p></li>
</ol>
</li>
<li><p><ins>(2.?) &mdash; Otherwise, <tt>iterator_category</tt> denotes 
<tt>input_iterator_tag</tt>.</ins></p></li>
</ol>
</blockquote>
</li>

</ol>
</blockquote>
<p><i>[2019-11-06, Tim updates P/R based on Belfast LWG evening session discussion]</i></p>

<p>
The check in the original P/R is incorrect; we want to check the transformation's result, not the base iterator.
</p>

<p><i>[2020-02-10 Move to Immediate Monday afternoon in Prague]</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.5.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> as indicated:</p>

<blockquote>
<p>
-2- <ins><tt>iterator::iterator_category</tt> is defined as follows:</ins> 
Let <tt>C</tt> denote the type <tt>iterator_traits&lt;iterator_t&lt;Base&gt;&gt;::iterator_category</tt>.
</p>
<ol style="list-style-type: none">
<li><p><ins>(2.?) &mdash; If <tt>is_lvalue_reference_v&lt;invoke_result_t&lt;F&amp;, range_reference_t&lt;Base&gt;&gt;&gt;</tt> 
is <tt>true</tt>,</ins></p>
<ol style="list-style-type: none">
<li><p><ins>(2.?.?) &mdash;</ins> If <tt>C</tt> models <tt>derived_from&lt;contiguous_iterator_tag&gt;</tt>, 
then <tt>iterator_category</tt> denotes <tt>random_access_iterator_tag</tt>;</p></li>
<li><p><ins>(2.?.?) &mdash;</ins> <ins>O</ins><del>o</del>therwise, <tt>iterator_category</tt> denotes 
<tt>C</tt>.</p></li>
</ol>
</li>
<li><p><ins>(2.?) &mdash; Otherwise, <tt>iterator_category</tt> denotes 
<tt>input_iterator_tag</tt>.</ins></p></li>
</ol>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3314" href="#3314">3314</a><sup><a href="https://cplusplus.github.io/LWG/issue3314">(i)</a></sup>. Is stream insertion behavior locale dependent when <tt>Period::type</tt> is <tt>micro</tt>?</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#Immediate">Immediate</a>
 <b>Submitter:</b> Tom Honermann <b>Opened:</b> 2019-11-04 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.5.10 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> states:
</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>
[&hellip;]
<p/>
-3- The units suffix depends on the type <tt>Period::type</tt> as follows:
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(3.5) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, the suffix is <tt>"&micro;s"</tt> 
(<tt>"\u00b5\u0073"</tt>).</p></li>
<li><p>[&hellip;]</p></li>
</ol>
<p/>
[&hellip;]
<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>, the unit suffix <tt>"us"</tt> is used instead of <tt>"&micro;s"</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
<p>
Which encoding is intended by "the encoding used for <tt>charT</tt>"?  There are two candidates:
</p>
<ol>
<li><p>The associated execution character set as defined by 5.3 <a href="https://wg21.link/lex.charset">[lex.charset]</a> p3 used to encode 
character and string literals (e.g., the "execution wide-character set" for <tt>wchar_t</tt>).</p></li>
<li><p>The locale dependent character set used by the <tt>std::locale ctype</tt> and <tt>codecvt</tt> 
facets as specified in 28.4.1 <a href="https://wg21.link/category.ctype">[category.ctype]</a>, sometimes referred to as the 
"native character set".</p></li>
</ol>
<p>
The behavior should not be dependent on <tt>locale</tt> and should therefore be specified in terms of 
the execution character sets.
<p/>
The execution character set is implementation defined and some implementations allow the choice of 
execution character set to be specified via a compiler option or determined based on the locale active 
when the compiler is run. For example, the Microsoft compiler, when run on a Windows system with regional 
language settings configured for "English (United States)", will use Windows-1252 for the execution 
character set, but allows this choice to be overridden with the <tt>/execution-charset</tt> compiler 
option. The Microsoft compiler might therefore use <tt>"us"</tt> by default, but <tt>"&micro;s"</tt> 
when invoked with the <tt>/execution-charset:utf-8</tt> or <tt>/execution-charset:.437</tt> options. 
In the latter two cases, the string contents would contain <tt>"\xb5\x73"</tt> and <tt>"\xe6\x73"</tt> 
respectively (Unicode and Windows code page 437 map &micro; (U+00B5, MICRO SIGN) to different code points).
<p/>
This resolution relies on the character set for the locale used at run-time being compatible with the 
execution character set if the produced string is to be displayed correctly when written to a terminal 
or console. This is a typical requirement for character and string literals but is more strongly 
relevant for this issue since &micro; lacks representation in many character sets. Additionally, if the 
stream is imbued with a <tt>std::codecvt</tt> facet, the facet must provide appropriate conversion 
support for behavior to be well defined.
</p>

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


<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<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 class="note">
<p>
[<i>Drafting note:</i> "implementation's native character set" is used in 28.4.1.1 <a href="https://wg21.link/locale.ctype">[locale.ctype]</a> 
and 28.4.1.4 <a href="https://wg21.link/locale.codecvt">[locale.codecvt]</a> to refer to the locale dependent character encoding.]
</p>
</blockquote>

<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>
[&hellip;]
<p/>
-3- The units suffix depends on the type <tt>Period::type</tt> as follows:
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(3.5) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, the suffix is <tt>"&micro;s"</tt> 
(<tt>"\u00b5\u0073"</tt>).</p></li>
<li><p>[&hellip;]</p></li>
</ol>
<p/>
[&hellip;]
<p/>
-4- If <tt>Period::type</tt> is <tt>micro</tt>, but the character U+00B5 <del>cannot be represented in the 
encoding used</del><ins>lacks representation in the execution character set</ins> for <tt>charT</tt>, the 
unit suffix <tt>"us"</tt> is used instead of <tt>"&micro;s"</tt>. <ins>If <tt>"&micro;s"</tt> is used but 
the implementation's native character set lacks representation for U+00B5 and the stream is associated 
with a terminal or console, or if the stream is imbued with a <tt>std::codecvt</tt> facet that lacks 
conversion support for the character, then the result is unspecified.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2019-11-12; Tom Honermann improves wording]</i></p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</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>
[&hellip;]
<p/>
-3- The units suffix depends on the type <tt>Period::type</tt> as follows:
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(3.5) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, <ins>it is implementation-defined 
whether</ins> the suffix is <tt>"&micro;s"</tt> (<tt>"\u00b5\u0073"</tt>) <ins>or <tt>"us"</tt></ins>.</p></li>
<li><p>[&hellip;]</p></li>
</ol>
<p/>
[&hellip;]
<p/>
<del>-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>, the unit suffix <tt>"us"</tt> is used instead of <tt>"&micro;s"</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3328" href="#3328">3328</a><sup><a href="https://cplusplus.github.io/LWG/issue3328">(i)</a></sup>. Clarify that <tt>std::string</tt> is not good for UTF-8</h3>
<p><b>Section:</b> D.19 <a href="https://wg21.link/depr.fs.path.factory">[depr.fs.path.factory]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> The Netherlands <b>Opened:</b> 2019-11-07 <b>Last modified:</b> 2020-02-12</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/371">NL 375</a></b></p>

<p>
Example in deprecated section implies that <tt>std::string</tt> is the type to use for utf8 strings.
</p>
<blockquote><p>
[<i>Example:</i> A string is to be read from a database that is encoded in UTF-8, and used
to create a directory using the native encoding for filenames:
<pre>
namespace fs = std::filesystem;
std::string utf8_string = read_utf8_data();
fs::create_directory(fs::u8path(utf8_string));
</pre>
</p></blockquote>
<p>
Proposed change:
</p>
<p>
Add clarification that <tt>std::string</tt> is the wrong type for utf8 strings
</p>
<p>
<b>Jeff Garland:</b>
<p/>
SG16 in Belfast: Recommend to accept with a modification to update the example in
D.19 <a href="https://wg21.link/depr.fs.path.factory">[depr.fs.path.factory]</a> p4 to state that <tt>std::u8string</tt> should
be preferred for UTF-8 data.
<p/>
Rationale: The example code is representative of historic use of <tt>std::filesystem::u8path</tt>
and should not be changed to use <tt>std::u8string</tt>. The recommended change is to a
non-normative example and may therefore be considered editorial.
</p>

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

<ol>
<li><p>Modify D.19 <a href="https://wg21.link/depr.fs.path.factory">[depr.fs.path.factory]</a> as indicated:</p>

<blockquote>
<p>
-4- [<i>Example:</i> A string is to be read from a database that is encoded in UTF-8,
and used to create a directory using the native encoding for filenames:
<blockquote><pre>
namespace fs = std::filesystem;
std::string utf8_string = read_utf8_data();
fs::create_directory(fs::u8path(utf8_string));
</pre></blockquote>
For POSIX-based operating systems with the native narrow encoding set to UTF-8,
no encoding or type conversion occurs.
<p/>
For POSIX-based operating systems with the native narrow encoding not set to UTF-8,
a conversion to UTF-32 occurs, followed by a conversion to the current native narrow
encoding. Some Unicode characters may have no native character set representation.
<p/>
For Windows-based operating systems a conversion from UTF-8 to UTF-16 occurs. &mdash;
<i>end example</i>]
<p/>
<ins>[<i>Note:</i> The example above is representative of historic use of
<tt>filesystem</tt> <tt>u8path</tt>. New code should use <tt>std::u8string</tt>
in place of <tt>std::string</tt>. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>

</ol>
</blockquote>

<p><em>LWG Belfast Friday Morning</em></p>
<p>
Requested changes:
<ul>
<li>Historic =&gt; historical.</li>
<li>Add missing :: before u8path.</li>
<li>Remove ISO rules forbidden 'should' in a note.</li>
<li>Use language describing why new code should use the u8string constructor
rather than preaching that new code should do something.</li>
</ul>
Billy O'Neal provides updated wording.
</p>

<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</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 D.19 <a href="https://wg21.link/depr.fs.path.factory">[depr.fs.path.factory]</a> as indicated:</p>

<blockquote>
<p>
-4- [<i>Example:</i> A string is to be read from a database that is encoded in UTF-8,
and used to create a directory using the native encoding for filenames:
<blockquote><pre>
namespace fs = std::filesystem;
std::string utf8_string = read_utf8_data();
fs::create_directory(fs::u8path(utf8_string));
</pre></blockquote>
For POSIX-based operating systems with the native narrow encoding set to UTF-8,
no encoding or type conversion occurs.
<p/>
For POSIX-based operating systems with the native narrow encoding not set to UTF-8,
a conversion to UTF-32 occurs, followed by a conversion to the current native narrow
encoding. Some Unicode characters may have no native character set representation.
<p/>
For Windows-based operating systems a conversion from UTF-8 to UTF-16 occurs. &mdash;
<i>end example</i>]
<p/>
<ins>[<i>Note:</i> The example above is representative of a historical use of
<tt>filesystem::u8path</tt>. Passing a <tt>std::u8string</tt> to <tt>path</tt>'s
constructor is preferred for an indication of UTF-8 encoding more consistent with
<tt>path</tt>'s handling of other encodings.  &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3334" href="#3334">3334</a><sup><a href="https://cplusplus.github.io/LWG/issue3334">(i)</a></sup>. <tt>basic_osyncstream</tt> move assignment and destruction calls <tt>basic_syncbuf::emit()</tt> twice</h3>
<p><b>Section:</b> 29.10.3 <a href="https://wg21.link/syncstream.osyncstream">[syncstream.osyncstream]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2019-11-06 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
These functions are specified to call <tt>emit()</tt>, which calls <tt>emit()</tt> on
the <tt>basic_syncbuf</tt> and sets <tt>badbit</tt> if it fails. Then, the move
assignment is specified to move-assign the <tt>basic_syncbuf</tt>, while the destructor
implicitly needs to destroy the <tt>basic_syncbuf</tt> data member. This calls <tt>emit()</tt>
on the <tt>basic_syncbuf</tt> again.
<p/>
Is this intended?
</p>
<p><i>[2020-02-13 Tim adds wording after discussion with Peter]</i></p>

<p><i>[2020-02 Status to Immediate Thursday afternoon in Prague.]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/N4849">N4849</a>.</p>
<blockquote class="note">
<p>
[<i>Drafting note:</i> There is no need to explicitly call <tt>emit</tt> at all in these functions;
memberwise move-assignment/destruction is sufficient, so we can strike the specification
entirely and rely on the wording in 16.4.2.3 <a href="https://wg21.link/functions.within.classes">[functions.within.classes]</a>. <i>&mdash; end drafting note</i>]
</p>
</blockquote>
<ol>
<li>
<p>Edit 29.10.3.2 <a href="https://wg21.link/syncstream.osyncstream.cons">[syncstream.osyncstream.cons]</a> as indicated:</p>
<blockquote>
<pre>
<del>~basic_osyncstream();</del>
</pre>
<blockquote>
<p><del>-6- <i>Effects:</i> Calls <tt>emit()</tt>. If an exception is thrown
from <tt>emit()</tt>, that exception is caught and ignored.</del></p>
</blockquote>
</blockquote>
</li>
<li>
<p>Strike 29.10.3.3 <a href="https://wg21.link/syncstream.osyncstream.assign">[syncstream.osyncstream.assign]</a>:</p>
<blockquote>
<pre>
<del>basic_osyncstream&amp; operator=(basic_osyncstream&amp;&amp; rhs) noexcept;</del>
</pre>
<blockquote>
<p><del>-1- <i>Effects:</i> First, calls <tt>emit()</tt>.
If an exception is thrown from <tt>emit()</tt>, that exception is caught and ignored.
Move assigns <tt>sb</tt> from <tt>rhs.sb</tt>. [ <i>Note:</i> This disassociates <tt>rhs</tt>
from its wrapped stream buffer ensuring destruction of <tt>rhs</tt> produces no output. — <i>end note</i> ]</del>
<p/>
<del>-2- <i>Postconditions:</i> <tt>nullptr == rhs.get_­wrapped()</tt> is <tt>true</tt>.
<tt>get_­wrapped()</tt> returns the value previously returned by <tt>rhs.get_­wrapped()</tt>.
</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3335" href="#3335">3335</a><sup><a href="https://cplusplus.github.io/LWG/issue3335">(i)</a></sup>. Resolve C++20 NB comments US 273 and GB 274</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#Immediate">Immediate</a>
 <b>Submitter:</b> United States/Great Britain <b>Opened:</b> 2019-11-08 <b>Last modified:</b> 2020-02-10</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/269">US 273</a>/<a href="https://github.com/cplusplus/nbballot/issues/270">GB 274</a></b></p>

<p>
<b><a href="https://github.com/cplusplus/nbballot/issues/269">US 273</a>:</b>
<p/>
<tt>all_view</tt> is not a view like the others. For the other view types, <tt>foo_view{args...}</tt> is a valid
way to construct an instance of type foo_view. However, <tt>all_view</tt> is just an alias to the type of 
<tt>view::all(arg)</tt>, which could be one of several different types. <tt>all_view</tt> feels like the wrong name.
<p/>
Proposed change:
<p/>
Suggest renaming <tt>all_view</tt> to <tt>all_t</tt> and
moving it into the <tt>views::</tt> namespace.
</p>

<p>
<b><a href="https://github.com/cplusplus/nbballot/issues/270">GB 274</a>:</b>
<p/>
Add <tt>range_size_t</tt>.
<p/>
LEWG asked that <tt>range_size_t</tt> be removed from <a href="https://wg21.link/p1035">P1035</a>, 
as they were doing a good job of being neutral w.r.t whether or not size-types were signed or 
unsigned at the time. Now that we've got a policy on what size-types are, and that 
<a href="https://wg21.link/p1522">P1522</a> and <a href="https://wg21.link/p1523">P1523</a> 
have been adopted, it makes sense for there to be a <tt>range_size_t</tt>.
<p/>
Proposed change:
<p/>
Add to [ranges.syn]:
</p>
<blockquote><pre>
template&lt;range R&gt;
  using range_difference_t = iter_difference_t&lt;iterator_t&lt;R&gt;&gt;;
<ins>template&lt;sized_range R&gt;
  using range_size_t = decltype(ranges::size(declval&lt;R&amp;&gt;()));</ins>
</pre></blockquote>
<p>
<b>David Olsen:</b>
<p/>
The proposed wording has been approved by LEWG and LWG in Belfast.
</p>

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

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

<p><i>[2020-02-10 Move to Immediate Monday afternoon in Prague]</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 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>, header <tt>&lt;ranges&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
#include &lt;initializer_list&gt;
#include &lt;iterator&gt;

namespace std::ranges {
  [&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>;
  [&hellip;]
  template&lt;range R&gt;
    using range_difference_t = iter_difference_t&lt;iterator_t&lt;R&gt;&gt;;
  <ins>template&lt;sized_range R&gt;
    using range_size_t = decltype(ranges::size(declval&lt;R&amp;&gt;()));</ins>
  template&lt;range R&gt;
    using range_value_t = iter_value_t&lt;iterator_t&lt;R&gt;&gt;;
  [&hellip;]
  <i>// 24.7.3.1 <a href="https://wg21.link/range.ref.view">[range.ref.view]</a>, all view</i>
  namespace views { <del>inline constexpr <i>unspecified</i> all = <i>unspecified</i>; }</del>
    <ins>inline constexpr <i>unspecified</i> all = <i>unspecified</i>;</ins>

    template&lt;viewable_range R&gt;
      using all_<ins>t</ins><del>view</del> = decltype(<del>views::</del>all(declval&lt;R&gt;()));
  <ins>}</ins>
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Globally replace all occurrences of <tt>all_view</tt> with <tt>views::all_t</tt>. There are 36 
occurrences in addition to the definition in the <tt>&lt;ranges&gt;</tt> synopsis that was changed above.</p>
</li>
</ol>




<hr>
<h3><a name="3340" href="#3340">3340</a><sup><a href="https://cplusplus.github.io/LWG/issue3340">(i)</a></sup>. Formatting functions should throw on argument/format string mismatch in &sect;[format.functions]</h3>
<p><b>Section:</b> 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Great Britain <b>Opened:</b> 2019-11-17 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#format.functions">active issues</a> in [format.functions].</p>
<p><b>View all other</b> <a href="lwg-index.html#format.functions">issues</a> in [format.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/226">GB 229</a></b></p>

<p>
Formatting functions don't allow throwing on incorrect arguments. 
<tt>std::format</tt> is only allowed to throw if <tt>fmt</tt> is not a format string, but the 
intention is it also throws for errors during formatting, e.g. there are fewer arguments than 
required by the format string.
</p>
<p>
Proposed change:
</p>
<p>
Allow exceptions even when the format string is valid. Possibly state the <i>Effects:</i> more
precisely.
</p>
<p>
<b>Victor Zverovich:</b>
<p/>
LEWG approved resolution of this NB comment as an LWG issue.
</p>

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

<blockquote class="note">
<p>
[<i>Drafting Note:</i> Depending on whether LWG <a href="lwg-defects.html#3336">3336</a>'s wording has been accepted when 
this issue's wording has been accepted, two mutually exclusive options are prepared, depicted below 
by <b>Option A</b> and <b>Option B</b>, respectively.]
</p>
</blockquote>

<p><b>Option A</b> (LWG <a href="lwg-defects.html#3336">3336</a> has been accepted)</p>

<ol>
<li><p>Change 20.20.2.1 <a href="https://wg21.link/format.string.general">[format.string.general]</a> as follows:</p>

<blockquote>
<p>
-1- A <i>format string</i> <ins>for arguments <tt>args</tt></ins> is a (possibly empty) sequence of 
<i>replacement fields</i>, <i>escape sequences</i>, and characters other than <tt>{</tt> and <tt>}</tt>. 
[&hellip;]
<p/>
-2- The <i>arg-id</i> field specifies the index of the argument in <tt>args</tt> whose value is to be 
formatted and inserted into the output instead of the replacement field. <ins>If there is no argument 
with the index <i>arg-id</i> in <tt>args</tt>, the string is not a format string.</ins> The optional 
<i>format-specifier</i> field explicitly specifies a format for the replacement value.
<p/>
[&hellip;]
<p/>
-5- The <i>format-spec</i> field contains <i>format specifications</i> that define how the value 
should be presented. Each type can define its own interpretation of the <i>format-spec</i> field. 
<ins>If <i>format-spec</i> doesn't conform to the format specifications for the argument in <tt>args</tt> 
referred to by <i>arg-id</i>, the string is not a format string.</ins> [&hellip;]
</p>
</blockquote>
</li>

<li><p>Before 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> insert a new sub-clause as indicated:</p>

<blockquote>
<p>
<ins><b>20.20.? Error reporting [format.err.report]</b></ins>
<p/>
<ins>-?- Formatting functions throw exceptions to report formatting and other errors. They throw 
<tt>format_error</tt> if an argument <tt>fmt</tt> is passed that is not a format string for arguments 
<tt>args</tt> and propagate exceptions thrown by <tt>formatter</tt> specializations and iterator operations. 
Failure to allocate storage is reported by throwing an exception as described in 
16.5.5.13 <a href="https://wg21.link/res.on.exception.handling">[res.on.exception.handling]</a>.</ins>
</p>
</blockquote>
</li>

<li><p>Modify 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> as indicated:</p>

<blockquote>
<pre>
string vformat(string_view fmt, format_args args);
wstring vformat(wstring_view fmt, wformat_args args);
string vformat(const locale&amp; loc, string_view fmt, format_args args);
wstring vformat(const locale&amp; loc, wstring_view fmt, wformat_args args);
</pre>
<blockquote>
<p>
-6- [&hellip;]
<p/>
-7- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out&gt;
  Out vformat_to(Out out, string_view fmt, format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, wstring_view fmt, format_args_t&lt;Out, wchar_t&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                 format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                 format_args_t&lt;Out, wchar_t&gt; args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      wstring_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, string_view fmt,
                                      const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, wstring_view fmt,
                                      const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class... Args&gt;
  size_t formatted_size(string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(wstring_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-25- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>

<p><b>Option B</b> (LWG <a href="lwg-defects.html#3336">3336</a> has <b>not</b> been accepted)</p>

<ol>
<li><p>Change 20.20.2.1 <a href="https://wg21.link/format.string.general">[format.string.general]</a> as follows:</p>

<blockquote>
<p>
-1- A <i>format string</i> <ins>for arguments <tt>args</tt></ins> is a (possibly empty) sequence of 
<i>replacement fields</i>, <i>escape sequences</i>, and characters other than <tt>{</tt> and <tt>}</tt>. 
[&hellip;]
<p/>
-2- The <i>arg-id</i> field specifies the index of the argument in <tt>args</tt> whose value is to be 
formatted and inserted into the output instead of the replacement field. <ins>If there is no argument 
with the index <i>arg-id</i> in <tt>args</tt>, the string is not a format string.</ins> The optional 
<i>format-specifier</i> field explicitly specifies a format for the replacement value.
<p/>
[&hellip;]
<p/>
-5- The <i>format-spec</i> field contains <i>format specifications</i> that define how the value 
should be presented. Each type can define its own interpretation of the <i>format-spec</i> field. 
<ins>If <i>format-spec</i> doesn't conform to the format specifications for the argument in <tt>args</tt> 
referred to by <i>arg-id</i>, the string is not a format string.</ins> [&hellip;]
</p>
</blockquote>
</li>

<li><p>Modify 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> as indicated:</p>

<blockquote>
<pre>
string vformat(string_view fmt, format_args args);
wstring vformat(wstring_view fmt, wformat_args args);
string vformat(const locale&amp; loc, string_view fmt, format_args args);
wstring vformat(const locale&amp; loc, wstring_view fmt, wformat_args args);
</pre>
<blockquote>
<p>
-6- [&hellip;]
<p/>
-7- <i>Throws:</i> <tt>format_error</tt> if <tt>fmt</tt> is not a format string <ins>for <tt>args</tt></ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out&gt;
  Out vformat_to(Out out, string_view fmt, format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, wstring_view fmt, format_args_t&lt;Out, wchar_t&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                 format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                 format_args_t&lt;Out, wchar_t&gt; args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Throws:</i> <tt>format_error</tt> if <tt>fmt</tt> is not a format string <ins>for <tt>args</tt></ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      wstring_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, string_view fmt,
                                      const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, wstring_view fmt,
                                      const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Throws:</i> <tt>format_error</tt> if <tt>fmt</tt> is not a format string <ins>for <tt>args</tt></ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class... Args&gt;
  size_t formatted_size(string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(wstring_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-25- <i>Throws:</i> <tt>format_error</tt> if <tt>fmt</tt> is not a format string <ins>for <tt>args</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-12, Prague; LWG discussion]</i></p>

<p>
Option A is the only one we look at to resolve LWG <a href="lwg-defects.html#3336">3336</a> as well. During the discussions some 
wording refinements have been suggested that are integrated below.
</p>


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

<ol>
<li><p>Change 20.20.2.1 <a href="https://wg21.link/format.string.general">[format.string.general]</a> as follows:</p>

<blockquote>
<p>
-1- A <i>format string</i> <ins>for arguments <tt>args</tt></ins> is a (possibly empty) sequence of 
<i>replacement fields</i>, <i>escape sequences</i>, and characters other than <tt>{</tt> and <tt>}</tt>. 
[&hellip;]
<p/>
-2- The <i>arg-id</i> field specifies the index of the argument in <tt>args</tt> whose value is to be 
formatted and inserted into the output instead of the replacement field. <ins>If there is no argument 
with the index <i>arg-id</i> in <tt>args</tt>, the string is not a format string for <tt>args</tt>.</ins> The optional 
<i>format-specifier</i> field explicitly specifies a format for the replacement value.
<p/>
[&hellip;]
<p/>
-5- The <i>format-spec</i> field contains <i>format specifications</i> that define how the value 
should be presented. Each type can define its own interpretation of the <i>format-spec</i> field. 
<ins>If <i>format-spec</i> does not conform to the format specifications for the argument type referred to 
by <i>arg-id</i>, the string is not a format string for <tt>args</tt>.</ins> [&hellip;]
</p>
</blockquote>
</li>

<li><p>Before 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> insert a new sub-clause as indicated:</p>

<blockquote>
<p>
<ins><b>20.20.? Error reporting [format.err.report]</b></ins>
<p/>
<ins>-?- Formatting functions throw <tt>format_error</tt> if an argument <tt>fmt</tt> is passed 
that is not a format string for <tt>args</tt>. They propagate exceptions thrown by operations of
<tt>formatter</tt> specializations and iterators. Failure to allocate storage is 
reported by throwing an exception as described in 16.5.5.13 <a href="https://wg21.link/res.on.exception.handling">[res.on.exception.handling]</a>.</ins>
</p>
</blockquote>
</li>

<li><p>Modify 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> as indicated:</p>

<blockquote>
<pre>
string vformat(string_view fmt, format_args args);
wstring vformat(wstring_view fmt, wformat_args args);
string vformat(const locale&amp; loc, string_view fmt, format_args args);
wstring vformat(const locale&amp; loc, wstring_view fmt, wformat_args args);
</pre>
<blockquote>
<p>
-6- [&hellip;]
<p/>
-7- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out&gt;
  Out vformat_to(Out out, string_view fmt, format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, wstring_view fmt, format_args_t&lt;Out, wchar_t&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                 format_args_t&lt;Out, char&gt; args);
template&lt;class Out&gt;
  Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                 format_args_t&lt;Out, wchar_t&gt; args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-15- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      wstring_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, string_view fmt,
                                      const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  format_to_n_result&lt;Out&gt; format_to_n(Out out, iter_difference_t&lt;Out&gt; n,
                                      const locale&amp; loc, wstring_view fmt,
                                      const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
[&hellip;]
<pre>
template&lt;class... Args&gt;
  size_t formatted_size(string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(wstring_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class... Args&gt;
  size_t formatted_size(const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-25- <i>Throws:</i> <del><tt>format_error</tt> if <tt>fmt</tt> is not a format string</del><ins>As specified in  [format.err.report]</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3347" href="#3347">3347</a><sup><a href="https://cplusplus.github.io/LWG/issue3347">(i)</a></sup>. <tt>std::pair&lt;T, U&gt;</tt> now requires <tt>T</tt> and <tt>U</tt> to be less-than-comparable</h3>
<p><b>Section:</b> 20.4.3 <a href="https://wg21.link/pairs.spec">[pairs.spec]</a>, 22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-12-03 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#pairs.spec">active issues</a> in [pairs.spec].</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.spec">issues</a> in [pairs.spec].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p1614r2">P1614R2</a> added <tt>operator&lt;=&gt;</tt> as a hidden friend to 
<tt>std::pair</tt>:
</p>
<blockquote>
<pre>
friend constexpr common_comparison_category_t&lt;<i>synth-three-way-result</i>&lt;T1&gt;, 
                                              <i>synth-three-way-result</i>&lt;T2&gt;&gt;
  operator&lt;=&gt;(const pair&amp; x, const pair&amp; y) { <i>see below</i> }
</pre>
</blockquote>
<p>
That is not a function template, so is not a SFINAE context. If one or both of 
<tt><i>synth-three-way-result</i>&lt;T1&gt;</tt> or <tt><i>synth-three-way-result</i>&lt;T2&gt;</tt> is an 
invalid type then the declaration of <tt>operator&lt;=&gt;</tt> is ill-formed, and so the specialization 
<tt>std::pair&lt;T1, T2&gt;</tt> is ill-formed.
<p/>
A similar problem exists for <tt>std::array</tt>.
<p/>
There are at least two ways to fix this:
</p>
<ol>
<li><p>Constrain the function and delay the use of synth-three-way-result until we know it's valid.</p></li>
<li><p>Replace the hidden friend with a namespace-scope function template, so invalid 
<tt><i>synth-three-way-result</i></tt> types cause substitution failure.</p></li>
</ol>
<p>
The first option is somewhat hard to specify, because current policy is to avoid the use of requires-clauses 
in most of the library clauses. Even with a requires-clause, the potentially-invalid 
<tt><i>synth-three-way-result</i></tt> types cannot be used in the function declarator. Furthermore, the 
<tt>operator&lt;=&gt;</tt> for <tt>std::array</tt> is currently specified in Table [tab:container.opt] and 
so there's nowhere to add a <i>Constraints:</i> element.
<p/>
The second option would partially revert the <a href="https://wg21.link/p1614r2">P1614R2</a> changes for 
<tt>std::pair</tt> and <tt>std::array</tt> and bring them closer to what was in C++17. The main motivation 
for making <tt>operator==</tt> a hidden friend was to allow it to be defaulted, so that <tt>std::pair</tt> 
and <tt>std::array</tt> would be usable as non-type template parameters. Following the acceptance of 
<a href="https://wg21.link/p1907">P1907</a> in Belfast it isn't necessary to default it, so we can go back 
to what was in C++17.
</p>

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

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

<p><i>[2020-02-10 Move to Immediate Monday afternoon in Prague]</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 20.2.1 <a href="https://wg21.link/utility.syn">[utility.syn]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> This restores the pre-<a href="https://wg21.link/p1614r2">P1614R2</a> 
<tt>operator==</tt> and uses <tt>operator&lt;=&gt;</tt> as replacement for
<tt>operator&lt;</tt>, <tt>operator&lt;=</tt>, <tt>operator&gt;</tt>, <tt>operator&gt;=</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
[&hellip;]

// 20.4 <a href="https://wg21.link/pairs">[pairs]</a>, class template pair
template&lt;class T1, class T2&gt;
struct pair;

<i>// 20.4.3 <a href="https://wg21.link/pairs.spec">[pairs.spec]</a>, pair specialized algorithms</i>
<ins>template&lt;class T1, class T2&gt;
  constexpr bool operator==(const pair&lt;T1, T2&gt;&amp;, const pair&lt;T1, T2&gt;&amp;);
template&lt;class T1, class T2&gt;
  constexpr common_comparison_category_t&lt;<i>synth-three-way-result</i>&lt;T1&gt;, 
                                         <i>synth-three-way-result</i>&lt;T2&gt;&gt;
  operator&lt;=&gt;(const pair&lt;T1, T2&gt;&amp;, const pair&lt;T1, T2&gt;&amp;);</ins>
  
template&lt;class T1, class T2&gt;
constexpr void swap(pair&lt;T1, T2&gt;&amp; x, pair&lt;T1, T2&gt;&amp; y) noexcept(noexcept(x.swap(y)));
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<pre>
  [&hellip;]
  constexpr void swap(pair&amp; p) noexcept(<i>see below</i>);
  
  <del><i>// 20.4.3 <a href="https://wg21.link/pairs.spec">[pairs.spec]</a>, pair specialized algorithms</i>
  friend constexpr bool operator==(const pair&amp;, const pair&amp;) = default;
  friend constexpr bool operator==(const pair&amp; x, const pair&amp; y)
    requires (is_reference_v&lt;T1&gt; || is_reference_v&lt;T2&gt;)
    { return x.first == y.first &amp;&amp; x.second == y.second; }
  friend constexpr common_comparison_category_t&lt;<i>synth-three-way-result</i>&lt;T1&gt;,
                                                <i>synth-three-way-result</i>&lt;T2&gt;&gt;
    operator&lt;=&gt;(const pair&amp; x, const pair&amp; y) { <i>see below</i> }</del>
};

template&lt;class T1, class T2&gt;
pair(T1, T2) -&gt; pair&lt;T1, T2&gt;;
[&hellip;]
</pre>
</blockquote>
</li>

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

<blockquote>
<p>
<b>20.4.3 Specialized algorithms [pairs.spec]</b>
</p>
<pre>
<ins>template&lt;class T1, class T2&gt;
  constexpr bool operator==(const pair&lt;T1, T2&gt;&amp; x, const pair&lt;T1, T2&gt;&amp; y);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns:</i> <tt>x.first == y.first &amp;&amp; x.second == y.second</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template&lt;class T1, class T2&gt;</ins>
<del>friend</del> constexpr
  common_comparison_category_t&lt;<i>synth-three-way-result</i>&lt;T1&gt;, <i>synth-three-way-result</i>&lt;T2&gt;&gt;
    operator&lt;=&gt;(const pair<ins>&lt;T1, T2&gt;</ins>&amp; x, const pair<ins>&lt;T1, T2&gt;</ins>&amp; y);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
if (auto c = <i>synth-three-way</i>(x.first, y.first); c != 0) return c;
return <i>synth-three-way</i>(x.second, y.second);
</pre></blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> This restores the pre-<a href="https://wg21.link/p1614r2">P1614R2</a> 
<tt>operator==</tt> and uses <tt>operator&lt;=&gt;</tt> as replacement for
<tt>operator&lt;</tt>, <tt>operator&lt;=</tt>, <tt>operator&gt;</tt>, <tt>operator&gt;=</tt>.]
</p>
</blockquote>

<blockquote>
<pre>
namespace std {

// 22.3.7 <a href="https://wg21.link/array">[array]</a>, class template array
template&lt;class T, size_t N&gt; struct array;

<ins>template&lt;class T, size_t N&gt;
  constexpr bool operator==(const array&lt;T, N&gt;&amp; x, const array&lt;T, N&gt;&amp; y);
template&lt;class T, size_t N&gt;
  constexpr <i>synth-three-way-result</i>&lt;T&gt;
    operator&lt;=&gt;(const array&lt;T, N&gt;&amp; x, const array&lt;T, N&gt;&amp; y);</ins>

template&lt;class T, size_t N&gt;
constexpr void swap(array&lt;T, N&gt;&amp; x, array&lt;T, N&gt;&amp; y) noexcept(noexcept(x.swap(y)));
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a> as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> there is no need to add definitions of <tt>operator==</tt> and 
<tt>operator&lt;=&gt;</tt> to  [array.spec] because they are defined by Table 71: 
Container requirements [tab:container.req] and Table 73: Optional container operations 
[tab:container.opt] respectively.]
</p>
</blockquote>

<blockquote>
<pre>
  [&hellip;]
  constexpr T * data() noexcept;
  constexpr const T * data() const noexcept;
  
  <del>friend constexpr bool operator==(const array&amp;, const array&amp;) = default;
  friend constexpr <i>synth-three-way-result</i>&lt;value_type&gt;
    operator&lt;=&gt;(const array&amp;, const array&amp;);</del>
};

template&lt;class T, class... U&gt;
array(T, U...) -&gt; array&lt;T, 1 + sizeof...(U)&gt;;
[&hellip;]
</pre>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3348" href="#3348">3348</a><sup><a href="https://cplusplus.github.io/LWG/issue3348">(i)</a></sup>. <tt>__cpp_lib_unwrap_ref</tt> in wrong header</h3>
<p><b>Section:</b> 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a>, 20.14.5.6 <a href="https://wg21.link/refwrap.unwrapref">[refwrap.unwrapref]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2019-12-03 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
cpplearner points out in <a href="https://github.com/BRevzin/sd6/issues/1">this github comment</a> that:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
Since <tt>unwrap_reference</tt> and <tt>unwrap_ref_decay</tt> are defined in <tt>&lt;functional&gt;</tt> 
([functional.syn]), their feature test macro should also be defined there.
</p>
</blockquote>
<p>
<a href="https://wg21.link/p1902r1">P1902R1</a> adds this feature test macro in <tt>&lt;type_traits&gt;</tt> instead. 
The feature test macro and the type traits should go into the same header: either both in <tt>&lt;functional&gt;</tt> 
or both in <tt>&lt;type_traits&gt;</tt>. 
<p/>
The smallest diff is just to move the macro into <tt>&lt;functional&gt;</tt>.
</p>

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

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

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<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_unordered_map_try_emplace 201411L <i>// also in &lt;unordered_map&gt;</i>
#define __cpp_lib_unwrap_ref                201811L <i>// also in &lt;<del>type_traits</del><ins>functional</ins>&gt;</i>
#define __cpp_lib_variant                   201606L <i>// also in &lt;variant&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
During LWG discussions it had been suggested that they considered it is an improvement to move the definitions of
<tt>unwrap_reference</tt> and <tt>unwrap_ref_decay</tt> from <tt>&lt;functional&gt;</tt> to <tt>&lt;type_traits&gt;</tt>.
This is what the alternative wording tries to accomplish.
</p>
<p><i>[Status to Immediate on Thursday night in Prague.]</i></p>



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

<ol>
<li><p>Modify 20.14.1 <a href="https://wg21.link/functional.syn">[functional.syn]</a>, header <tt>&lt;functional&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
[&hellip;]
<del>template&lt;class T&gt; struct unwrap_reference;
template&lt;class T&gt; using unwrap_reference_t = typename unwrap_reference&lt;T&gt;::type;
template&lt;class T&gt; struct unwrap_ref_decay;
template&lt;class T&gt; using unwrap_ref_decay_t = typename unwrap_ref_decay&lt;T&gt;::type;</del>
[&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Delete sub-clause 20.14.5.6 <a href="https://wg21.link/refwrap.unwrapref">[refwrap.unwrapref]</a> completely, as indicated:</p>
<blockquote>
<p>
<del><b>20.14.5.6 Transformation type trait <tt>unwrap_reference</tt> [refwrap.unwrapref]</b></del>
</p>
<pre>
<del>template&lt;class T&gt;
  struct unwrap_reference;</del>
</pre>
<blockquote>
<p>
<del>-1- If <tt>T</tt> is a specialization <tt>reference_wrapper&lt;X&gt;</tt> for some type <tt>X</tt>, the member typedef 
<tt>type</tt> of <tt>unwrap_reference&lt;T&gt;</tt> is <tt>X&amp;</tt>, otherwise it is <tt>T</tt>.</del>
</p>
</blockquote>
<pre>
<del>template&lt;class T&gt;
  struct unwrap_ref_decay;</del>
</pre>
<blockquote>
<p>
<del>-2- The member typedef <tt>type</tt> of <tt>unwrap_ref_decay&lt;T&gt;</tt> denotes the type 
<tt>unwrap_reference_t&lt;decay_t&lt;T&gt;&gt;</tt>.</del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.15.2 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, header <tt>&lt;type_traits&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
namespace std {
[&hellip;]
<i>// 20.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a>, other transformations</i>
[&hellip;]
template&lt;class T&gt; struct underlying_type;
template&lt;class Fn, class... ArgTypes&gt; struct invoke_result;
<ins>template&lt;class T&gt; struct unwrap_reference;
template&lt;class T&gt; struct unwrap_ref_decay;</ins>

template&lt;class T&gt;
  using type_identity_t = typename type_identity&lt;T&gt;::type;
[&hellip;]
template&lt;class Fn, class... ArgTypes&gt;
  using invoke_result_t = typename invoke_result&lt;Fn, ArgTypes...&gt;::type;
<ins>template&lt;class T&gt; 
  using unwrap_reference_t = typename unwrap_reference&lt;T&gt;::type;
template&lt;class T&gt; 
  using unwrap_ref_decay_t = typename unwrap_ref_decay&lt;T&gt;::type;</ins>
template&lt;class...&gt;
  using void_t = void;
[&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 20.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a>, Table 55 &mdash; "Sign modifications" in  [tab:meta.trans.sign] as indicated:</p>

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

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<ins><tt>template &lt;class T&gt;<br/>
struct unwrap_reference;</tt></ins>
</td>
<td>
<ins>If <tt>T</tt> is a specialization <tt>reference_wrapper&lt;X&gt;</tt> for some type <tt>X</tt>, the member typedef 
<tt>type</tt> of <tt>unwrap_reference&lt;T&gt;</tt> is <tt>X&amp;</tt>, otherwise it is <tt>T</tt>.</ins>
</td>
</tr>

<tr>
<td>
<ins><tt>template &lt;class T&gt;<br/>
struct unwrap_ref_decay;</tt></ins>
</td>
<td>
<ins>The member typedef <tt>type</tt> of <tt>unwrap_ref_decay&lt;T&gt;</tt> denotes the type 
<tt>unwrap_reference_t&lt;decay_t&lt;T&gt;&gt;</tt>.</ins>
</td>
</tr>
</table>

</li>

<li><p>Insert between 20.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a> p1 and p2 as indicated:</p>
<blockquote>
<p>
<ins>In addition to being available via inclusion of the <tt>&lt;type_traits&gt;</tt> header, the templates 
<tt>unwrap_reference</tt>, <tt>unwrap_ref_decay</tt>, <tt>unwrap_reference_t</tt>, and <tt>unwrap_ref_decay_t</tt> 
are available when the header <tt>&lt;functional&gt;</tt> (20.14.1 <a href="https://wg21.link/functional.syn">[functional.syn]</a>) is included.</ins>
</p>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3352" href="#3352">3352</a><sup><a href="https://cplusplus.github.io/LWG/issue3352">(i)</a></sup>. <tt>strong_equality</tt> isn't a thing</h3>
<p><b>Section:</b> 22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-12-06 <b>Last modified:</b> 2020-02-12</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements.general">active issues</a> in [container.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements.general">issues</a> in [container.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[tab:container.req] includes the row:
</p>
<blockquote>
<p>
<b>Expression:</b> <tt>i &lt;=&gt; j</tt>
<p/>
<b>Return Type:</b> <tt>strong_ordering</tt> if <tt>X::iterator</tt> meets the random access iterator requirements, 
otherwise <tt>strong_equality</tt>.
<p/>
<b>Complexity:</b> constant
</p>
</blockquote>
<p>
"<tt>strong_equality</tt>" is (now) a meaningless term that appears nowhere else in the working draft. Presumably 
we want to make the Return Type unconditionally <tt>strong_ordering</tt>, and require this expression to be 
valid only when <tt>i</tt> and <tt>j</tt> are random access iterators. It's not clear to me if the best way to 
do so would be to add a "<i>Constraints</i>" to the "Assertion/note/pre-/post-condition" column of this table row, 
or if we should pull the row out into yet another "conditionally-supported iterator requirements" table.
</p>

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

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

<p><i>[2020-02-10, Prague; David Olsen provides new wording based upon Tim Songs suggestion]</i></p>

<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</i></p>



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

<blockquote>
<table border="1">
<caption>Table 71 &mdash; Container requirements [tab:container.req]</caption>
<tr style="text-align:center">
<th>Expression</th>
<th>Return type</th>
<th>Operational<br/>semantics</th>
<th>Assertion/note<br/>pre/post-condition</th>
<th>Complexity</th>
</tr>
<tr>
<td colspan="5" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>i &lt;=&gt; j</tt>
</td>
<td>
<tt>strong_ordering</tt> <del>if<br/>
<tt>X::iterator</tt> meets the<br/>
random access iterator<br/>
requirements, otherwise<br/>
<tt>strong_equality</tt></del>
</td>
<td></td>
<td>
<ins><i>Constraints:</i> <tt>X::iterator</tt> meets the random access iterator requirements.</ins>
</td>
<td>
constant
</td>
</tr>

<tr>
<td colspan="5" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>




<hr>
<h3><a name="3354" href="#3354">3354</a><sup><a href="https://cplusplus.github.io/LWG/issue3354">(i)</a></sup>. <tt>has_strong_structural_equality</tt> has a meaningless definition</h3>
<p><b>Section:</b> 20.15.4.3 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a>, 17.3.2 <a href="https://wg21.link/version.syn">[version.syn]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2019-12-08 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
After the Belfast 2019 meeting with the acceptance of <a href="https://wg21.link/p1907r1">P1907R1</a>
the core language term "strong structural equality" has been removed and instead a more general 
definition of a "structural type" has been introduced that is suitable to be used as non-type template
parameter. These changes have caused the current definition of the <tt>has_strong_structural_equality</tt>
type trait (which had originally been introduced by <a href="https://wg21.link/p1614r2">P1614R2</a>
during the Cologne 2019 meeting) to become meaningless since it is currently defined as follows:
</p>
<blockquote>
<p>
The type <tt>T</tt> has strong structural equality (11.11.1 <a href="https://wg21.link/class.compare.default">[class.compare.default]</a>).
</p>
</blockquote>
<p>
Besides the now undefined term "strong structural equality", the reference to 11.11.1 <a href="https://wg21.link/class.compare.default">[class.compare.default]</a>
doesn't make sense anymore, assuming that the trait definition is supposed to refer now to a type that 
can be used as non-type template parameter.
<p/>
During library reflector discussions several informal naming suggestions has been mentioned, such as
<tt>is_structural[_type]</tt>, <tt>can_be_nttp</tt>, <tt>is_nontype_template_parameter_type</tt>.
<p/>
Albeit <tt>is_structural_type</tt> would come very near to the current core terminology, core experts 
have argued that the term "structural type" should be considered as a "core-internal" term that may
easily be replaced post-C++20.
<p/>
In addition to that definition and naming question of that type trait it should be discussed whether
there should exist a specific feature macro for just this type trait, similar to the reason why we 
introduced the <tt>__cpp_lib_has_unique_object_representations</tt> test macro for the
<tt>has_unique_object_representations</tt> type trait while voting in 
<a href="https://wg21.link/p0258r2">P0258R2</a>. The submitter of this issue believes that such a feature 
macro should be added and given that its final definition should be related to the date of the
acceptance of this issue (and should <em>not</em> be related to any historically accepted papers such as 
<a href="https://wg21.link/p1614r2">P1614R2</a>).
</p>

<p><i>[2020-01 Priority set to 1 and questions to LEWG after review on the reflector.]</i></p>


<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<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 (The
symbolic <tt>??????L</tt> represents the date to be defined by the project editor):</p>

<blockquote>
<pre>
[&hellip;]
#define __cpp_lib_is_swappable               201603L <i>// also in &lt;type_traits&gt;</i>
<ins>#define __cpp_lib_is_template_parameter_type ??????L <i>// also in &lt;type_traits&gt;</i></ins>
#define __cpp_lib_jthread                    201911L <i>// also in &lt;stop_token&gt;, &lt;thread&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.15.2 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, header <tt>&lt;type_traits&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt; struct has_unique_object_representations;

template&lt;class T&gt; struct <del>has_strong_structural_equality</del><ins>is_template_parameter_type</ins>;

<i>// 20.15.5 <a href="https://wg21.link/meta.unary.prop.query">[meta.unary.prop.query]</a>, type property queries</i>
[&hellip;]
template&lt;class T&gt;
  inline constexpr bool has_unique_object_representations_v
    = has_unique_object_representations&lt;T&gt;::value;

template&lt;class T&gt;
  inline constexpr bool <del>has_strong_structural_equality_v</del><ins>is_template_parameter_type_v</ins>
    = <del>has_strong_structural_equality</del><ins>is_template_parameter_type</ins>&lt;T&gt;::value;
    
<i>// 20.15.5 <a href="https://wg21.link/meta.unary.prop.query">[meta.unary.prop.query]</a>, type property queries</i>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.15.2 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, Table 47 ([tab:meta.unary.prop]) &mdash; 
"Type property predicates" &mdash; as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 47: Type property predicates [tab:meta.unary.prop]</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

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

<tr>
<td>
<tt>template&lt;class T&gt;<br/>
struct<br/>
<del>has_strong_structural_equality</del><ins>is_template_parameter_type</ins>;</tt>
</td>

<td>
The type <tt>T</tt> <del>has strong<br/>
structural<br/>
equality (11.11.1 <a href="https://wg21.link/class.compare.default">[class.compare.default]</a>)</del><br/>
<ins>can be used as non-type<br/>
<i>template-parameter</i> (13.2 <a href="https://wg21.link/temp.param">[temp.param]</a>)</ins>.
</td>

<td>
<del><tt>T</tt> shall be a complete type,<br/>
<i>cv</i> <tt>void</tt>, or an array of<br/>
unknown bound.</del><br/>
<ins>If <tt>T</tt> is a class type, <tt>T</tt> shall<br/>
be a complete type.</ins>
</td>
</tr>

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

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

</ol>
</blockquote>

<p><i>[2020-02, Prague]</i></p>

<p>
LEWG looked at this and suggested to remove the existing trait <tt>has_strong_structural_equality</tt>
for now until someone demonstrates which usecases exist that would justify its existence.
</p>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Set to Immediate.
</p>


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

<ol>
<li><p>Modify 20.15.2 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, header <tt>&lt;type_traits&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt; struct has_unique_object_representations;

<del>template&lt;class T&gt; struct has_strong_structural_equality;</del>

<i>// 20.15.5 <a href="https://wg21.link/meta.unary.prop.query">[meta.unary.prop.query]</a>, type property queries</i>
[&hellip;]
template&lt;class T&gt;
  inline constexpr bool has_unique_object_representations_v
    = has_unique_object_representations&lt;T&gt;::value;

<del>template&lt;class T&gt;
  inline constexpr bool has_strong_structural_equality_v
    = has_strong_structural_equality&lt;T&gt;::value;</del>
    
<i>// 20.15.5 <a href="https://wg21.link/meta.unary.prop.query">[meta.unary.prop.query]</a>, type property queries</i>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.15.2 <a href="https://wg21.link/meta.type.synop">[meta.type.synop]</a>, Table 47 ([tab:meta.unary.prop]) &mdash; 
"Type property predicates" &mdash; as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 47: Type property predicates [tab:meta.unary.prop]</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

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

<tr>
<td>
<del><tt>template&lt;class T&gt;<br/>
struct<br/>
has_strong_structural_equality;</tt></del>
</td>

<td>
<del>The type <tt>T</tt> has strong<br/>
structural<br/>
equality (11.11.1 <a href="https://wg21.link/class.compare.default">[class.compare.default]</a>).</del>
</td>

<td>
<del><tt>T</tt> shall be a complete type,<br/>
<i>cv</i> <tt>void</tt>, or an array of<br/>
unknown bound.</del>
</td>
</tr>
</table>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3355" href="#3355">3355</a><sup><a href="https://cplusplus.github.io/LWG/issue3355">(i)</a></sup>. The memory algorithms should support move-only input iterators introduced by P1207</h3>
<p><b>Section:</b> 20.10.11.5 <a href="https://wg21.link/uninitialized.copy">[uninitialized.copy]</a>, 20.10.11.6 <a href="https://wg21.link/uninitialized.move">[uninitialized.move]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Corentin Jabot <b>Opened:</b> 2019-11-12 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#uninitialized.copy">issues</a> in [uninitialized.copy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p1207">P1207</a> introduced move-only input iterators but did not modify the 
specialized memory algorithms to support them.
</p>

<p><i>[2020-01 Priority set to 2 after review on the reflector.]</i></p>

<p><i>[2020-02 Status to Immediate on Friday morning in Prague.]</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 20.10.11.5 <a href="https://wg21.link/uninitialized.copy">[uninitialized.copy]</a> as indicated:</p>

<blockquote>
<pre>
namespace ranges {
  template&lt;input_iterator I, sentinel_for&lt;I&gt; S1,
           <i>no-throw-forward-iterator</i> O, <i>no-throw-sentinel</i>&lt;O&gt; S2&gt;
      requires constructible_from&lt;iter_value_t&lt;O&gt;, iter_reference_t&lt;I&gt;&gt;
    uninitialized_copy_result&lt;I, O&gt;
      uninitialized_copy(I ifirst, S1 ilast, O ofirst, S2 olast);
  template&lt;input_range IR, <i>no-throw-forward-range</i> OR&gt;
      requires constructible_from&lt;range_value_t&lt;OR&gt;, range_reference_t&lt;IR&gt;&gt;
    uninitialized_copy_result&lt;safe_iterator_t&lt;IR&gt;, safe_iterator_t&lt;OR&gt;&gt;
      uninitialized_copy(IR&amp;&amp; in_range, OR&amp;&amp; out_range);
}
</pre>
<blockquote>
<p>
-4- <i>Preconditions:</i> <tt>[ofirst, olast)</tt> shall not overlap with <tt>[ifirst, ilast)</tt>.
<p/>
-5- <i>Effects:</i> Equivalent to:
<blockquote><pre>
for (; ifirst != ilast &amp;&amp; ofirst != olast; ++ofirst, (void)++ifirst) {
  ::new (<i>voidify</i>(*ofirst)) remove_reference_t&lt;iter_reference_t&lt;O&gt;&gt;(*ifirst);
}
return {<ins>std::move(</ins>ifirst<ins>)</ins>, ofirst};
</pre></blockquote>
</p>
</blockquote>
[&hellip;]
<pre>
namespace ranges {
  template&lt;input_iterator I, <i>no-throw-forward-iterator</i> O, <i>no-throw-sentinel</i>&lt;O&gt; S&gt;
      requires constructible_from&lt;iter_value_t&lt;O&gt;, iter_reference_t&lt;I&gt;&gt;
    uninitialized_copy_n_result&lt;I, O&gt;
      uninitialized_copy_n(I ifirst, iter_difference_t&lt;I&gt; n, O ofirst, S olast);
}
</pre>
<blockquote>
<p>
-9- <i>Preconditions:</i> <tt>[ofirst, olast)</tt> shall not overlap with <tt>[ifirst, n)</tt>.
<p/>
-10- <i>Effects:</i> Equivalent to:
<blockquote><pre>
auto t = uninitialized_copy(counted_iterator(ifirst, n),
                            default_sentinel, ofirst, olast);
return {<ins>std::move(</ins>t.in<ins>)</ins>.base(), t.out};
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.10.11.6 <a href="https://wg21.link/uninitialized.move">[uninitialized.move]</a> as indicated:</p>

<blockquote>
<pre>
namespace ranges {
  template&lt;input_iterator I, sentinel_for&lt;I&gt; S1,
           <i>no-throw-forward-iterator</i> O, <i>no-throw-sentinel</i>&lt;O&gt; S2&gt;
      requires constructible_from&lt;iter_value_t&lt;O&gt;, iter_rvalue_reference_t&lt;I&gt;&gt;
    uninitialized_move_result&lt;I, O&gt;
      uninitialized_move(I ifirst, S1 ilast, O ofirst, S2 olast);
  template&lt;input_range IR, <i>no-throw-forward-range</i> OR&gt;
      requires constructible_from&lt;range_value_t&lt;OR&gt;, range_rvalue_reference_t&lt;IR&gt;&gt;
    uninitialized_move_result&lt;safe_iterator_t&lt;IR&gt;, safe_iterator_t&lt;OR&gt;&gt;
      uninitialized_move(IR&amp;&amp; in_range, OR&amp;&amp; out_range);
}
</pre>
<blockquote>
<p>
-3- <i>Preconditions:</i> <tt>[ofirst, olast)</tt> shall not overlap with <tt>[ifirst, ilast)</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to:
<blockquote><pre>
for (; ifirst != ilast &amp;&amp; ofirst != olast; ++ofirst, (void)++ifirst) {
  ::new (<i>voidify</i>(*ofirst)) 
    remove_reference_t&lt;iter_reference_t&lt;O&gt;&gt;(ranges::iter_move(*ifirst));
}
return {<ins>std::move(</ins>ifirst<ins>)</ins>, ofirst};
</pre></blockquote>
</p>
</blockquote>
[&hellip;]
<pre>
namespace ranges {
  template&lt;input_iterator I, <i>no-throw-forward-iterator</i> O, <i>no-throw-sentinel</i>&lt;O&gt; S&gt;
      requires constructible_from&lt;iter_value_t&lt;O&gt;, iter_rvalue_reference_t&lt;I&gt;&gt;
    uninitialized_move_n_result&lt;I, O&gt;
      uninitialized_move_n(I ifirst, iter_difference_t&lt;I&gt; n, O ofirst, S olast);
}
</pre>
<blockquote>
<p>
-8- <i>Preconditions:</i> <tt>[ofirst, olast)</tt> shall not overlap with <tt>[ifirst, n)</tt>.
<p/>
-9- <i>Effects:</i> Equivalent to:
<blockquote><pre>
auto t = uninitialized_move(counted_iterator(ifirst, n),
                            default_sentinel, ofirst, olast);
return {<ins>std::move(</ins>t.in<ins>)</ins>.base(), t.out};
</pre></blockquote>
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3358" href="#3358">3358</a><sup><a href="https://cplusplus.github.io/LWG/issue3358">(i)</a></sup>. &sect;[span.cons] is mistaken that <tt>to_address</tt> can throw</h3>
<p><b>Section:</b> 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-12-10 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#span.cons">active issues</a> in [span.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#span.cons">issues</a> in [span.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
[span.cons] paragraphs 6 and 9:
</p>
<blockquote><p>
<i>Throws:</i> When and what <tt>to_address(first)</tt> throws.
</p></blockquote>
<p>
could equivalently be "<i>Throws:</i> Nothing." since all overloads of <tt>std::to_address</tt> are 
<tt>noexcept</tt>. However, paragraph 9 fails to account for the fact that paragraph 8:
</p>
<blockquote><p>
<i>Effects:</i> Initializes <tt>data_</tt> with <tt>to_address(first)</tt> and <tt>size_</tt> with 
<tt>last - first</tt>.
</p></blockquote>
<p>
must evaluate <tt>last - first</tt>.
</p>

<p><i>[2020-01-14 Status set to Tentatively Ready after ten positive votes on the reflector.]</i></p>


<p><i>[2020-01-14; Daniel comments]</i></p>

<p>
The fixed wording in 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> p9 depends on the no-throw-guarantee of integer-class
conversions to integral types. This guarantee is specified by LWG <a href="lwg-active.html#3367">3367</a>.
</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 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> paragraphs 6 and 9 as indicated:</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> 
<ol>
<li><p>The missing paragraph number of the <i>Preconditions</i> element at p7/p8 has
already been reported as <a href="https://github.com/cplusplus/draft/issues/3540">editorial issue</a></p></li>
<li><p>The effective change to "Throws: Nothing." in p6 has already been 
<a href="https://github.com/cplusplus/draft/commit/e01989e83849323ab49089ea18a52ccbac08d90a">applied editorially</a>.</p></li>
</ol>
]
</p>
</blockquote>

<blockquote>
<pre>
template&lt;class It&gt;
  constexpr span(It first, size_type count);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Preconditions:</i> [&hellip;]
<p/>
-5- <i>Effects:</i> Initializes <tt>data_</tt> with <tt>to_address(first)</tt> and <tt>size_</tt> with 
<tt>count</tt>.
<p/>
-6- <i>Throws:</i> <del>When and what <tt>to_address(first)</tt> throws</del><ins>Nothing</ins>.
</p>
</blockquote>
<pre>
template&lt;class It, class End&gt;
  constexpr span(It first, End last);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-?- <i>Preconditions:</i> [&hellip;]
<p/>
-8- <i>Effects:</i> Initializes <tt>data_</tt> with <tt>to_address(first)</tt> and <tt>size_</tt> 
with <tt>last - first</tt>.
<p/>
-9- <i>Throws:</i> When and what <tt><del>to_address(first)</del><ins>last - first</ins></tt> throws.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3359" href="#3359">3359</a><sup><a href="https://cplusplus.github.io/LWG/issue3359">(i)</a></sup>. <tt>&lt;chrono&gt;</tt> leap second support should allow for negative leap seconds</h3>
<p><b>Section:</b> 27.11.8 <a href="https://wg21.link/time.zone.leap">[time.zone.leap]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Asher Dunn <b>Opened:</b> 2019-12-16 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>class leap</tt> (which is expected to be renamed by <a href="https://wg21.link/p1981r0">P1981R0</a> to
<tt>leap_second</tt>) defined in 27.11.8 <a href="https://wg21.link/time.zone.leap">[time.zone.leap]</a> should include support for both
positive leap seconds (<tt>23:59:60</tt> added to UTC at a specified time) and negative leap seconds
(<tt>23:59:59</tt> removed from UTC at a specified time). While only positive leap seconds have been
inserted to date, the definition of UTC allows for both.
<p/>
Update 27.11.8 <a href="https://wg21.link/time.zone.leap">[time.zone.leap]</a> to specify the value of leap seconds in addition to
their insertion date, and update wording and examples in 27.7 <a href="https://wg21.link/time.clock">[time.clock]</a> and
27.12 <a href="https://wg21.link/time.format">[time.format]</a> that involve leap seconds to account for both types of leap second.
</p>

<p><i>[2020-01 Priority set to 3 after review on the reflector.]</i></p>


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

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

<blockquote>
<pre>
template&lt;class Duration&gt;
  static sys_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;
    to_sys(const utc_time&lt;Duration&gt;&amp; u);
</pre>
<blockquote>
<p>
-2- <i>Returns:</i> A <tt>sys_time t</tt>, such that <tt>from_sys(t) == u</tt> if such a mapping exists.
Otherwise <tt>u</tt> represents a <tt>time_point</tt> during a <ins>positive</ins> leap second
insertion<ins>, the conversion counts that leap second as not inserted,</ins> and the last
representable value of <tt>sys_time</tt> prior to the insertion of the leap second is returned.
</p>
</blockquote>
<pre>
template&lt;class Duration&gt;
  static utc_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;
    from_sys(const sys_time&lt;Duration&gt;&amp; t);
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> A <tt>utc_time u</tt>, such that <tt>u.time_since_epoch() - t.time_since_epoch()</tt>
is equal to the <del>number</del><ins>sum</ins> of leap seconds that were inserted between <tt>t</tt>
and 1970-01-01. If <tt>t</tt> is exactly the date of leap second insertion, then the conversion counts
that leap second as inserted.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Duration&gt;
  leap_second_info get_leap_second_info(const utc_time&lt;Duration&gt;&amp; ut);
</pre>
<blockquote>
<p>
-6- <i>Returns:</i> A <tt>leap_second_info</tt> where <tt>is_leap_second</tt> is <tt>true</tt> if
<tt>ut</tt> is during a <ins>positive</ins> leap second insertion, and otherwise <tt>false</tt>.
<tt>elapsed</tt> is the <del>number</del><ins>sum</ins> of leap seconds between 1970-01-01 and
<tt>ut</tt>. If <tt>is_leap_second</tt> is <tt>true</tt>, the leap second referred to by <tt>ut</tt>
is included in the count.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<p>
-1- The clock <tt>tai_clock</tt> measures seconds since 1958-01-01 00:00:00 and is offset 10s ahead of
UTC at this date. That is, 1958-01-01 00:00:00 TAI is equivalent to 1957-12-31 23:59:50 UTC. Leap seconds
are not inserted into TAI. Therefore every time a leap second is inserted into UTC, UTC <del>falls another
second behind</del><ins>shifts another second with respect to</ins> TAI. For example by 2000-01-01 there
had been 22 <ins>positive and 0 negative</ins> leap seconds inserted so 2000-01-01 00:00:00 UTC is
equivalent to 2000-01-01 00:00:32 TAI (22s plus the initial 10s offset).
</p>
</blockquote>
</li>

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

<blockquote>
<p>
-1- The clock <tt>gps_clock</tt> measures seconds since the first Sunday of January, 1980 00:00:00 UTC.
Leap seconds are not inserted into GPS. Therefore every time a leap second is inserted into UTC, UTC
<del>falls another second behind</del><ins>shifts another second with respect to</ins> GPS. Aside from
the offset from <tt>1958y/January/1</tt> to <tt>1980y/January/Sunday[1]</tt>, GPS is behind TAI by 19s
due to the 10s offset between 1958 and 1970 and the additional 9 leap seconds inserted between 1970 and 1980.
</p>
</blockquote>
</li>

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

<blockquote>
<pre>
namespace std::chrono {
  class leap {
  public:
    leap(const leap&amp;) = default;
    leap&amp; operator=(const leap&amp;) = default;

    <i>// unspecified additional constructors</i>

    constexpr sys_seconds date() const noexcept;
    <ins>constexpr seconds value() const noexcept;</ins>
  };
}
</pre>
<p>
-1- Objects of type <tt>leap</tt> representing the date <ins>and value</ins> of the leap second
insertions are constructed and stored in the time zone database when initialized.
<p/>
-2- [<i>Example:</i>
</p>
<blockquote><pre>
for (auto&amp; l : get_tzdb().leaps)
  if (l &lt;= 2018y/March/17d)
    cout &lt;&lt; l.date() &lt;&lt; <ins>": " &lt;&lt; l.value() &lt;&lt;</ins> '\n';
</pre></blockquote>
<p>
Produces the output:
</p>
<blockquote><pre>
1972-07-01 00:00:00<ins>: 1s</ins>
1973-01-01 00:00:00<ins>: 1s</ins>
1974-01-01 00:00:00<ins>: 1s</ins>
1975-01-01 00:00:00<ins>: 1s</ins>
1976-01-01 00:00:00<ins>: 1s</ins>
1977-01-01 00:00:00<ins>: 1s</ins>
1978-01-01 00:00:00<ins>: 1s</ins>
1979-01-01 00:00:00<ins>: 1s</ins>
1980-01-01 00:00:00<ins>: 1s</ins>
1981-07-01 00:00:00<ins>: 1s</ins>
1982-07-01 00:00:00<ins>: 1s</ins>
1983-07-01 00:00:00<ins>: 1s</ins>
1985-07-01 00:00:00<ins>: 1s</ins>
1988-01-01 00:00:00<ins>: 1s</ins>
1990-01-01 00:00:00<ins>: 1s</ins>
1991-01-01 00:00:00<ins>: 1s</ins>
1992-07-01 00:00:00<ins>: 1s</ins>
1993-07-01 00:00:00<ins>: 1s</ins>
1994-07-01 00:00:00<ins>: 1s</ins>
1996-01-01 00:00:00<ins>: 1s</ins>
1997-07-01 00:00:00<ins>: 1s</ins>
1999-01-01 00:00:00<ins>: 1s</ins>
2006-01-01 00:00:00<ins>: 1s</ins>
2009-01-01 00:00:00<ins>: 1s</ins>
2012-07-01 00:00:00<ins>: 1s</ins>
2015-07-01 00:00:00<ins>: 1s</ins>
2017-01-01 00:00:00<ins>: 1s</ins>
</pre></blockquote>
<p>
&mdash; <i>end example</i>]
</p>
</blockquote>
</li>

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

<blockquote>
<pre>
constexpr sys_seconds date() const noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> The date and time at which the leap second was inserted.
</p>
</blockquote>
<pre>
<ins>constexpr seconds value() const noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns:</i> The value of the leap second. Always <tt>+1s</tt> to indicate a positive
leap second or <tt>-1s</tt> to indicate a negative leap second. All leap seconds inserted up
through 2017 were positive leap seconds.</ins>
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Duration, class charT&gt;
  struct formatter&lt;chrono::utc_time&lt;Duration&gt;, charT&gt;;
</pre>
<blockquote>
<p>
-7- <i>Remarks:</i> If <tt>%Z</tt> is used, it is replaced with
<tt><i>STATICALLY-WIDEN</i>&lt;charT&gt;("UTC")</tt>. If <tt>%z</tt> (or a modified
variant of <tt>%z</tt>) is used, an offset of <tt>0min</tt> is formatted. If the argument represents
a time during a <ins>positive</ins> leap second insertion, and if a seconds field is formatted,
the integral portion of that format is <tt><i>STATICALLY-WIDEN</i>&lt;charT&gt;("60")</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-14; Prague]</i></p>

<p>
LWG Review. Some wording improvements have been made and lead to revised wording.
</p>


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

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

<blockquote>
<pre>
template&lt;class Duration&gt;
  static sys_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;
    to_sys(const utc_time&lt;Duration&gt;&amp; u);
</pre>
<blockquote>
<p>
-2- <i>Returns:</i> A <tt>sys_time t</tt>, such that <tt>from_sys(t) == u</tt> if such a mapping exists.
Otherwise <tt>u</tt> represents a <tt>time_point</tt> during a <ins>positive</ins> leap second
insertion<ins>, the conversion counts that leap second as not inserted,</ins> and the last
representable value of <tt>sys_time</tt> prior to the insertion of the leap second is returned.
</p>
</blockquote>
<pre>
template&lt;class Duration&gt;
  static utc_time&lt;common_type_t&lt;Duration, seconds&gt;&gt;
    from_sys(const sys_time&lt;Duration&gt;&amp; t);
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> A <tt>utc_time u</tt>, such that <tt>u.time_since_epoch() - t.time_since_epoch()</tt>
is equal to the <del>number</del><ins>sum</ins> of leap seconds that were inserted between <tt>t</tt>
and 1970-01-01. If <tt>t</tt> is exactly the date of leap second insertion, then the conversion counts
that leap second as inserted.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Duration&gt;
  leap_second_info get_leap_second_info(const utc_time&lt;Duration&gt;&amp; ut);
</pre>
<blockquote>
<p>
-6- <i>Returns:</i> A <tt>leap_second_info</tt><ins>, <tt>lsi</tt>,</ins> where <tt><ins>lsi.</ins>is_leap_second</tt> 
is <tt>true</tt> if <tt>ut</tt> is during a <ins>positive</ins> leap second insertion, and otherwise <tt>false</tt>.
<tt><ins>lsi.</ins>elapsed</tt> is the <del>number</del><ins>sum</ins> of leap seconds between 1970-01-01 and
<tt>ut</tt>. If <tt><ins>lsi.</ins>is_leap_second</tt> is <tt>true</tt>, the leap second referred to by <tt>ut</tt>
is included in the <del>count</del><ins>sum</ins>.
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<p>
-1- The clock <tt>tai_clock</tt> measures seconds since 1958-01-01 00:00:00 and is offset 10s ahead of
UTC at this date. That is, 1958-01-01 00:00:00 TAI is equivalent to 1957-12-31 23:59:50 UTC. Leap seconds
are not inserted into TAI. Therefore every time a leap second is inserted into UTC, UTC <del>falls another
second behind</del><ins>shifts another second with respect to</ins> TAI. For example by 2000-01-01 there
had been 22 <ins>positive and 0 negative</ins> leap seconds inserted so 2000-01-01 00:00:00 UTC is
equivalent to 2000-01-01 00:00:32 TAI (22s plus the initial 10s offset).
</p>
</blockquote>
</li>

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

<blockquote>
<p>
-1- The clock <tt>gps_clock</tt> measures seconds since the first Sunday of January, 1980 00:00:00 UTC.
Leap seconds are not inserted into GPS. Therefore every time a leap second is inserted into UTC, UTC
<del>falls another second behind</del><ins>shifts another second with respect to</ins> GPS. Aside from
the offset from <tt>1958y/January/1</tt> to <tt>1980y/January/Sunday[1]</tt>, GPS is behind TAI by 19s
due to the 10s offset between 1958 and 1970 and the additional 9 leap seconds inserted between 1970 and 1980.
</p>
</blockquote>
</li>

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

<blockquote>
<pre>
namespace std::chrono {
  class leap {
  public:
    leap(const leap&amp;) = default;
    leap&amp; operator=(const leap&amp;) = default;

    <i>// unspecified additional constructors</i>

    constexpr sys_seconds date() const noexcept;
    <ins>constexpr seconds value() const noexcept;</ins>
  };
}
</pre>
<p>
-1- Objects of type <tt>leap</tt> representing the date <ins>and value</ins> of the leap second
insertions are constructed and stored in the time zone database when initialized.
<p/>
-2- [<i>Example:</i>
</p>
<blockquote><pre>
for (auto&amp; l : get_tzdb().leaps)
  if (l &lt;= 2018y/March/17d)
    cout &lt;&lt; l.date() &lt;&lt; <ins>": " &lt;&lt; l.value() &lt;&lt;</ins> '\n';
</pre></blockquote>
<p>
Produces the output:
</p>
<blockquote><pre>
1972-07-01 00:00:00<ins>: 1s</ins>
1973-01-01 00:00:00<ins>: 1s</ins>
1974-01-01 00:00:00<ins>: 1s</ins>
1975-01-01 00:00:00<ins>: 1s</ins>
1976-01-01 00:00:00<ins>: 1s</ins>
1977-01-01 00:00:00<ins>: 1s</ins>
1978-01-01 00:00:00<ins>: 1s</ins>
1979-01-01 00:00:00<ins>: 1s</ins>
1980-01-01 00:00:00<ins>: 1s</ins>
1981-07-01 00:00:00<ins>: 1s</ins>
1982-07-01 00:00:00<ins>: 1s</ins>
1983-07-01 00:00:00<ins>: 1s</ins>
1985-07-01 00:00:00<ins>: 1s</ins>
1988-01-01 00:00:00<ins>: 1s</ins>
1990-01-01 00:00:00<ins>: 1s</ins>
1991-01-01 00:00:00<ins>: 1s</ins>
1992-07-01 00:00:00<ins>: 1s</ins>
1993-07-01 00:00:00<ins>: 1s</ins>
1994-07-01 00:00:00<ins>: 1s</ins>
1996-01-01 00:00:00<ins>: 1s</ins>
1997-07-01 00:00:00<ins>: 1s</ins>
1999-01-01 00:00:00<ins>: 1s</ins>
2006-01-01 00:00:00<ins>: 1s</ins>
2009-01-01 00:00:00<ins>: 1s</ins>
2012-07-01 00:00:00<ins>: 1s</ins>
2015-07-01 00:00:00<ins>: 1s</ins>
2017-01-01 00:00:00<ins>: 1s</ins>
</pre></blockquote>
<p>
&mdash; <i>end example</i>]
</p>
</blockquote>
</li>

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

<blockquote>
<pre>
constexpr sys_seconds date() const noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns:</i> The date and time at which the leap second was inserted.
</p>
</blockquote>
<pre>
<ins>constexpr seconds value() const noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Returns:</i> <tt>+1s</tt> to indicate a positive leap second or <tt>-1s</tt> to indicate a negative leap second. 
[<i>Note:</i> All leap seconds inserted up through 2019 were positive leap seconds. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;class Duration, class charT&gt;
  struct formatter&lt;chrono::utc_time&lt;Duration&gt;, charT&gt;;
</pre>
<blockquote>
<p>
-7- <i>Remarks:</i> If <tt>%Z</tt> is used, it is replaced with
<tt><i>STATICALLY-WIDEN</i>&lt;charT&gt;("UTC")</tt>. If <tt>%z</tt> (or a modified
variant of <tt>%z</tt>) is used, an offset of <tt>0min</tt> is formatted. If the argument represents
a time during a <ins>positive</ins> leap second insertion, and if a seconds field is formatted,
the integral portion of that format is <tt><i>STATICALLY-WIDEN</i>&lt;charT&gt;("60")</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3362" href="#3362">3362</a><sup><a href="https://cplusplus.github.io/LWG/issue3362">(i)</a></sup>. Strike <tt>stop_source</tt>'s <tt>operator!=</tt></h3>
<p><b>Section:</b> 32.3.4 <a href="https://wg21.link/stopsource">[stopsource]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-01-03 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Just like <tt>stop_token</tt> (see LWG <a href="lwg-active.html#3254">3254</a>), <tt>stop_source</tt> in 32.3.4 <a href="https://wg21.link/stopsource">[stopsource]</a>
declares an <tt>operator!=</tt> friend that is unnecessary in light of the new core language rules and 
should be struck.
</p>

<p><i>[2020-01-14 Status set to Tentatively Ready after six positive votes on the reflector.]</i></p>



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

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

<blockquote>
<pre>
namespace std {
  [&hellip;]

  class stop_source {
  public:
    [&hellip;]

    [[nodiscard]] friend bool
    operator==(const stop_source&amp; lhs, const stop_source&amp; rhs) noexcept;
    <del>[[nodiscard]] friend bool
    operator!=(const stop_source&amp; lhs, const stop_source&amp; rhs) noexcept;</del>
    friend void swap(stop_source&amp; lhs, stop_source&amp; rhs) noexcept;
  };
}
</pre>
</blockquote>

</li>

<li><p>Modify 32.3.4.3 <a href="https://wg21.link/stopsource.cmp">[stopsource.cmp]</a> and 32.3.4.4 <a href="https://wg21.link/stopsource.special">[stopsource.special]</a> as indicated:</p>

<blockquote>
<p>
<b>32.3.4.3 <ins>Non-member functions</ins><del>Comparisons</del> [stopsource.<ins>nonmembers</ins><del>cmp</del>]</b>
</p>
<pre>
[[nodiscard]] bool operator==(const stop_source&amp; lhs, const stop_source&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_source&amp; lhs, const stop_source&amp; rhs) noexcept;</del>
</pre>
<blockquote>
<p>
<del>-2- <i>Returns:</i> <tt>!(lhs==rhs)</tt>.</del>
</p>
</blockquote>
<p>
<del><b>32.3.4.4 Specialized algorithms [stopsource.special]</b></del>
</p>
<pre>
friend void swap(stop_source&amp; x, stop_source&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="3363" href="#3363">3363</a><sup><a href="https://cplusplus.github.io/LWG/issue3363">(i)</a></sup>. <tt>drop_while_view</tt> should opt-out of <tt>sized_range</tt></h3>
<p><b>Section:</b> 24.7.9.2 <a href="https://wg21.link/range.drop.while.view">[range.drop.while.view]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2020-01-07 <b>Last modified:</b> 2020-02-12</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>If <tt>drop_while_view</tt>'s <tt>iterator_t</tt> and <tt>sentinel_t</tt>
model <tt>forward_iterator</tt> and <tt>sized_sentinel_for</tt>, it will 
incorrectly satisfy <tt>sized_range</tt> thanks to the size member function
inherited from <tt>view_interface</tt>.</p>

<p>Because it has to compute its <tt>begin()</tt>, it can never model 
<tt>sized_range</tt> due to not meeting its non-amortized O(1) requirement.</p>

<p><i>[2020-01-16 Priority set to 1 after discussion on the reflector.]</i></p>


<p><i>[2020-02-10; Prague 2020; Casey comments and provides alternative wording]</i></p>

<p>
The fundamental issue here is that both <tt>ranges::size</tt> and <tt>view_interface::size</tt> 
(it should be unsurprising that many of the "default" implementations of member <tt>meow</tt> in 
<tt>view_interface</tt> look just like fallback cases of the <tt>ranges::meow</tt> CPO) have 
a case that returns the difference of <tt>ranges::end</tt> and <tt>ranges::begin</tt>. If 
<tt>begin</tt> and <tt>end</tt> are amortized* O(1) but not "true" O(1), then the resulting 
<tt>size</tt> operation is amortized O(1) and not "true" O(1) as required by the 
<tt>sized_range</tt> concept. I don't believe we can or should fix this on a case by case basis,
but we should instead relax the complexity requirement for <tt>sized_range</tt> to be 
handwavy-amortized O(1).
</p>

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

<ol>
<li><p>Add the following specialization to 24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>:</p>

<blockquote>
<pre>
// [drop.while.view], drop while view
  template&lt;view V, class Pred&gt;
    requires input_range&lt;V&gt; &amp;&amp; is_object_v&lt;Pred&gt; &amp;&amp;
      indirect_unary_predicate&lt;const Pred, iterator_t&lt;V&gt;&gt;
    class drop_while_view;

<ins>
  template&lt;view V, class Pred&gt;
    inline constexpr bool disable_sized_range&lt;drop_while_view&lt;V, Pred&gt;&gt; = true;
</ins>

  namespace views { inline constexpr unspecified drop_while = unspecified; }
</pre>
</blockquote>

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

<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</i></p>



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

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

<blockquote>
<p>
-2- Given an lvalue <tt>t</tt> of type <tt>remove_reference_t&lt;T&gt;</tt>, <tt>T</tt> models 
<tt>sized_range</tt> only if
</p>
<ol style="list-style-type: none"> 
<li><p>(2.1) &mdash; <tt>ranges::size(t)</tt> is <ins>amortized</ins> &#x1d4aa;(<tt>1</tt>), does not modify <tt>t</tt>, 
and is equal to <tt>ranges::distance(t)</tt>, and</p></li>
<li><p>[&hellip;]</p></li>
</ol>
<p>
<del>-3- [<i>Note:</i> The complexity requirement for the evaluation of <tt>ranges::size</tt> is non-amortized, unlike the
case for the complexity of the evaluations of <tt>ranges::begin</tt> and <tt>ranges::end</tt> in the <tt>range</tt> concept.
&mdash; <i>end note</i>]</del>
</p>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3364" href="#3364">3364</a><sup><a href="https://cplusplus.github.io/LWG/issue3364">(i)</a></sup>. Initialize data members of ranges and their iterators</h3>
<p><b>Section:</b> 24.7.7.2 <a href="https://wg21.link/range.take.while.view">[range.take.while.view]</a>, 24.7.8.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a>, 24.7.9.2 <a href="https://wg21.link/range.drop.while.view">[range.drop.while.view]</a>, 24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2020-01-07 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#range.take.while.view">issues</a> in [range.take.while.view].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>Before <a href="http://wg21.link/p1035">P1035</a> was accepted, no data member in [ranges] whose type could
potentially be an aggregate or fundamental type was left without initializer. P1035 left some such data members 
without initializer, so it is possible to have them have indeterminate values. We propose restoring consistency.</p>

<p><i>[2020-01-14 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="http://wg21.link/N4842">N4842</a>.</p>

<ol>
<li><p>Modify 24.7.7.2 <a href="https://wg21.link/range.take.while.view">[range.take.while.view]</a> as follows:</p>
<blockquote>
<pre>
class take_while_view : public view_interface&lt;take_while_view&lt;V, Pred&gt;&gt; {
  template&lt;bool&gt; class sentinel;                      <i>// exposition only</i>

  V base_ <ins>= V()</ins>;                                      <i>// exposition only</i>
  semiregular-box&lt;Pred&gt; pred_;                        <i>// exposition only</i>

public:
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.8.2 <a href="https://wg21.link/range.drop.view">[range.drop.view]</a> as follows:</p>
<blockquote>
<pre>
private:
  V base_ <ins>= V()</ins>;                                     <i>// exposition only</i>
  range_difference_t&lt;V&gt; count_ <ins>= 0</ins>;                  <i>// exposition only</i>
};
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.9.2 <a href="https://wg21.link/range.drop.while.view">[range.drop.while.view]</a> as follows:</p>
<blockquote>
<pre>
private:
  V base_ <ins>= V()</ins>;                                     <i>// exposition only</i>
  semiregular-box&lt;Pred&gt; pred_;                       <i>// exposition only</i>
};
</pre>
</blockquote>
</li>

<li><p>Modify 24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> as follows:</p>
<blockquote>
<pre>
class elements_view&lt;V, N&gt;::iterator {                <i>// exposition only</i>
  using base-t = conditional_t&lt;Const, const V, V&gt;;
  friend iterator&lt;!Const&gt;;

  iterator_t&lt;base-t&gt; current_ <ins>= iterator_t&lt;base-t&gt;()</ins>;
public:
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3367" href="#3367">3367</a><sup><a href="https://cplusplus.github.io/LWG/issue3367">(i)</a></sup>. Integer-class conversions should not throw</h3>
<p><b>Section:</b> 23.3.4.4 <a href="https://wg21.link/iterator.concept.winc">[iterator.concept.winc]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-07 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.concept.winc">active issues</a> in [iterator.concept.winc].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.concept.winc">issues</a> in [iterator.concept.winc].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It's widely established that neither conversions of integral types to <tt>bool</tt> nor conversions 
between different integral types throw exceptions. These properties are crucial to supporting exception 
guarantees in algorithms, containers, and other uses of iterators and their difference types. 
Integer-class types must provide the same guarantees to support the same use cases as do integer types.
</p>

<p><i>[2020-01-14; Daniel comments]</i></p>

<ol>
<li><p>We probably need to think about providing the stronger guarantee that all integer-class operations 
are also <tt>noexcept</tt> in addition to the guarantee that they do not throw any exceptions.</p></li>
<li><p>The fixed wording in LWG <a href="lwg-active.html#3358">3358</a>, 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> p9 depends on the no-throw-guarantee 
of integer-class conversions to integral types.</p></li>
</ol>

<p><i>[2020-01-25 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="http://wg21.link/n4842">N4842</a>.</p>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> There's a bit of drive-by editing here to change occurrences of the meaningless 
"type is convertible to type" to "expression is convertible to type". Paragraph 7 only has drive-by edits. ]
</p>
</blockquote>

<blockquote>
<p>
-6- <del>All</del><ins>Expressions of</ins> integer-class type<del>s</del> are explicitly convertible to 
<del>all</del><ins>any</ins> integral type<del>s and</del><ins>. Expressions of integral type are both</ins>
implicitly and explicitly convertible <del>from all integral types</del><ins>to any integer-class type. 
Conversions between integral and integer-class types do not exit via an exception</ins>.
<p/>
-7- <del>All</del><ins>Expressions <tt><i>E</i></tt> of</ins> integer-class type<del>s</del> <ins><tt>I</tt></ins> 
are contextually convertible to <tt>bool</tt> as if by <tt>bool(<del>a</del><ins><i>E</i></ins> != I(0))</tt><del>, 
where <tt>a</tt> is an instance of the integral-class type <tt>I</tt></del>.
</p>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3369" href="#3369">3369</a><sup><a href="https://cplusplus.github.io/LWG/issue3369">(i)</a></sup>. <tt>span</tt>'s deduction-guide for built-in arrays doesn't work</h3>
<p><b>Section:</b> 22.7.3.1 <a href="https://wg21.link/span.overview">[span.overview]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2020-01-08 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#span.overview">active issues</a> in [span.overview].</p>
<p><b>View all other</b> <a href="lwg-index.html#span.overview">issues</a> in [span.overview].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://wg21.link/n4842">N4842</a> 22.7.3.1 [span.overview] depicts:
</p>
<blockquote><pre>
template&lt;class T, size_t N&gt;
span(T (&amp;)[N]) -&gt; span&lt;T, N&gt;;
</pre></blockquote> 
<p>
This isn't constrained by 22.7.3.3 [span.deduct]. Then, 22.7.3.2 [span.cons]/10 
specifies:
</p>
<blockquote><pre>
template&lt;size_t N&gt; constexpr span(element_type (&amp;arr)[N]) noexcept;
template&lt;size_t N&gt; constexpr span(array&lt;value_type, N&gt;&amp; arr) noexcept;
template&lt;size_t N&gt; constexpr span(const array&lt;value_type, N&gt;&amp; arr) noexcept;
</pre>
<blockquote>
<p>
<i>Constraints:</i>
</p>
<ul>
<li><p><tt>extent == dynamic_extent || N == extent</tt> is <tt>true</tt>, and</p></li>
<li><p><tt>remove_pointer_t&lt;decltype(data(arr))&gt;(*)[]</tt> is convertible to 
<tt>ElementType(*)[]</tt>.</p></li>
</ul>
</blockquote>
</blockquote>
<p>
Together, these cause CTAD to behave unexpectedly. Here's a minimal test case, reduced from libcxx's 
test suite:
</p>
<blockquote><pre>
C:\Temp&gt;type span_ctad.cpp
#include &lt;stddef.h&gt;
#include &lt;type_traits&gt; 

inline constexpr size_t dynamic_extent = static_cast&lt;size_t&gt;(-1);

template &lt;typename T, size_t Extent = dynamic_extent&gt;
struct span {
  template &lt;size_t Size&gt;
  requires (Extent == dynamic_extent || Extent == Size)
#ifdef WORKAROUND_WITH_TYPE_IDENTITY_T
  span(std::type_identity_t&lt;T&gt; (&amp;)[Size]) {}
#else
  span(T (&amp;)[Size]) {}
#endif
};

template &lt;typename T, size_t Extent&gt;
#ifdef WORKAROUND_WITH_REQUIRES_TRUE
requires (true)
#endif
span(T (&amp;)[Extent]) -&gt; span&lt;T, Extent&gt;;

int main() {
  int arr[] = {1,2,3};
  span s{arr};
  static_assert(std::is_same_v&lt;decltype(s), span&lt;int, 3&gt;&gt;,
    "CTAD should deduce span&lt;int, 3&gt;.");
}

C:\Temp&gt;cl /EHsc /nologo /W4 /std:c++latest span_ctad.cpp
span_ctad.cpp
span_ctad.cpp(26): error C2338: CTAD should deduce span&lt;int, 3&gt;.

C:\Temp&gt;cl /EHsc /nologo /W4 /std:c++latest /DWORKAROUND_WITH_TYPE_IDENTITY_T span_ctad.cpp
span_ctad.cpp

C:\Temp&gt;cl /EHsc /nologo /W4 /std:c++latest /DWORKAROUND_WITH_REQUIRES_TRUE span_ctad.cpp
span_ctad.cpp

C:\Temp&gt;
</pre></blockquote> 
<p>
(MSVC and GCC 10 demonstrate this behavior. Clang is currently affected by 
<a href="https://bugs.llvm.org/show_bug.cgi?id=44484">LLVM#44484</a>.)
<p/>
Usually, when there's an explicit deduction-guide, we can ignore any corresponding constructor, 
because the overload resolution tiebreaker 12.4.3 [over.match.best]/2.10 prefers deduction-guides. 
However, this is a mental shortcut only, and it's possible for guides generated from constructors 
to out-compete deduction-guides during CTAD. That's what's happening here.
<p/>
Specifically, the constructor is constrained, while the deduction-guide is not constrained. This 
activates the "more specialized" tiebreaker first (12.4.3 [over.match.best]/2.5 is considered before 
/2.10 for deduction-guides). That goes through 13.7.6.2 [temp.func.order]/2 and 13.5.4 [temp.constr.order] 
to prefer the more constrained overload.
<p/>
(In the test case, this results in <tt>span&lt;int, dynamic_extent&gt;</tt> being deduced. That's 
because the constructor allows <tt>T</tt> to be deduced to be <tt>int</tt>. The constructor's <tt>Size</tt> 
template parameter is deduced to be 3, but that's unrelated to the class's <tt>Extent</tt> parameter. 
Because <tt>Extent</tt> has a default argument of <tt>dynamic_extent</tt>, CTAD succeeds and deduces 
<tt>span&lt;int, dynamic_extent&gt;</tt>.)
<p/>
There are at least two possible workarounds: we could alter the constructor to prevent it from 
participating in CTAD, or we could constrain the deduction-guide, as depicted in the test case. Either 
way, we should probably include a Note, following the precedent of 21.3.2.2 [string.cons]/12.
<p/>
Note that there are also deduction-guides for span from <tt>std::array</tt>. However, the constructors 
take <tt>array&lt;value_type, N&gt;</tt> with <tt>using value_type = remove_cv_t&lt;ElementType&gt;;</tt> 
so that prevents the constructors from interfering with CTAD.
<p/>
I'm currently proposing to alter the constructor from built-in arrays. An alternative resolution to 
constrain the deduction-guide would look like: "<i>Constraints:</i> <tt>true</tt>. [<i>Note:</i> This 
affects class template argument deduction. &mdash; <i>end note</i>]"
</p>

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



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4842">N4842</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:
  [&hellip;]
  <i>// 22.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a>, constructors, copy, and assignment</i>
  constexpr span() noexcept;
  [&hellip;]
  template&lt;size_t N&gt;
  constexpr span(<ins>type_identity_t&lt;</ins>element_type<ins>&gt;</ins> (&amp;arr)[N]) noexcept;
  [&hellip;]
};
[&hellip;]
</pre>
</blockquote>

</li>

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

<blockquote>
<pre>
template&lt;size_t N&gt; constexpr span(<ins>type_identity_t&lt;</ins>element_type<ins>&gt;</ins> (&amp;arr)[N]) noexcept;
template&lt;size_t N&gt; constexpr span(array&lt;value_type, N&gt;&amp; arr) noexcept;
template&lt;size_t N&gt; constexpr span(const array&lt;value_type, N&gt;&amp; arr) noexcept;
</pre>
<blockquote>
<p>
-10- <i>Constraints:</i>
<ol style="list-style-type: none">
<li><p>(10.1) &mdash; <tt>extent == dynamic_extent || N == extent</tt> is <tt>true</tt>, and</p></li>
<li><p>(10.2) &mdash; <tt>remove_pointer_t&lt;decltype(data(arr))&gt;(*)[]</tt> is convertible to 
<tt>ElementType(*)[]</tt>.</p></li>
</ol>
<p/>
-11- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the supplied array. <ins>[<i>Note:</i> 
<tt>type_identity_t</tt> affects class template argument deduction. &mdash; <i>end note</i>]</ins>
<p/>
-12- <i>Postconditions:</i> <tt>size() == N &amp;&amp; data() == data(arr)</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3371" href="#3371">3371</a><sup><a href="https://cplusplus.github.io/LWG/issue3371">(i)</a></sup>. <tt>visit_format_arg</tt> and <tt>make_format_args</tt> are not hidden friends</h3>
<p><b>Section:</b> 20.20.5.1 <a href="https://wg21.link/format.arg">[format.arg]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-01-16 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#format.arg">issues</a> in [format.arg].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
After <a href="https://wg21.link/P1965R0">P1965R0</a>, friend function and function template
declarations always introduce hidden friends under the new blanket wording in
16.5.5.6 <a href="https://wg21.link/hidden.friends">[hidden.friends]</a>. However, 20.20.5.1 <a href="https://wg21.link/format.arg">[format.arg]</a> contains
"exposition only" friend declarations of <tt>visit_format_arg</tt> and <tt>make_format_args</tt>,
and those are not intended to be hidden. The only reason to have these declarations in the first
place is because these function templates are specified using the exposition-only private data
members of <tt>basic_format_arg</tt>, but that's unnecessary &mdash; for example,
<tt>shared_ptr</tt>'s constructors are not exposition-only friends of <tt>enable_shared_from_this</tt>,
even though the former are shown as assigning to the latter's exposition-only <tt>weak_this</tt>
private data member (see 20.11.3.1 <a href="https://wg21.link/util.smartptr.shared.const">[util.smartptr.shared.const]</a>p1).
</p>

<p><i>[2020-02-01 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="http://wg21.link/n4842">N4842</a>.</p>

<ol>
<li><p>Edit 20.20.5.1 <a href="https://wg21.link/format.arg">[format.arg]</a>, class template <tt>basic_format_arg</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class Context&gt;
  class basic_format_arg {

    [&hellip;]

<del>    template&lt;class Visitor, class Ctx&gt;
      friend auto visit_format_arg(Visitor&amp;&amp; vis,
                                   basic_format_arg&lt;Ctx&gt; arg);                  // <i>exposition only</i>

    template&lt;class Ctx, class... Args>
      friend <i>format-arg-store</i>&lt;Ctx, Args...&gt;
        make_format_args(const Args&amp;... args);                                  // <i>exposition only</i></del>

    [&hellip;]
  };
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3372" href="#3372">3372</a><sup><a href="https://cplusplus.github.io/LWG/issue3372">(i)</a></sup>. <tt>vformat_to</tt> should not try to deduce <tt>Out</tt> twice</h3>
<p><b>Section:</b> 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-01-16 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#format.functions">active issues</a> in [format.functions].</p>
<p><b>View all other</b> <a href="lwg-index.html#format.functions">issues</a> in [format.functions].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>vformat_to</tt> currently deduces <tt>Out</tt> from its first and last arguments.
This requires its last argument's type to be a specialization of <tt>basic_format_args</tt>,
which notably prevents the use of <tt><i>format-arg-store</i></tt> arguments directly.
This is unnecessary: we should only deduce from the first argument.
</p>

<p><i>[2020-02-01 Status set to Tentatively Ready after six positive votes on the reflector.]</i></p>



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

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

<blockquote>
<pre>
namespace std {

  [&hellip;]

  template&lt;class Out&gt;
    Out vformat_to(Out out, string_view fmt, format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, char&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, wstring_view fmt, format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, wchar_t&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                   format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, char&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                   format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, wchar_t&gt; args);

  [&hellip;]
}
</pre>
</blockquote>
</li>
<li><p>Edit 20.20.3 <a href="https://wg21.link/format.functions">[format.functions]</a> p8 through p10 as indicated:</p>

<blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p> -8- <i>Effects:</i> Equivalent to:</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(out, fmt, <del>{</del>make_format_args&lt;context&gt;(args...)<del>}</del>);
</pre>
</blockquote>
</blockquote>
<pre>
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, string_view fmt, const Args&amp;... args);
template&lt;class Out, class... Args&gt;
  Out format_to(Out out, const locale&amp; loc, wstring_view fmt, const Args&amp;... args);
</pre>
<blockquote>
<p> -9- <i>Effects:</i> Equivalent to:</p>
<blockquote>
<pre>
using context = basic_format_context&lt;Out, decltype(fmt)::value_type&gt;;
return vformat_to(out, loc, fmt, <del>{</del>make_format_args&lt;context&gt;(args...)<del>}</del>);
</pre>
</blockquote>
</blockquote>
<pre>
  template&lt;class Out&gt;
    Out vformat_to(Out out, string_view fmt, format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, char&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, wstring_view fmt, format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, wchar_t&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, const locale&amp; loc, string_view fmt,
                   format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, char&gt; args);
  template&lt;class Out&gt;
    Out vformat_to(Out out, const locale&amp; loc, wstring_view fmt,
                   format_args_t&lt;<ins>type_identity_t&lt;</ins>Out<ins>&gt;</ins>, wchar_t&gt; args);
</pre>
<blockquote>
<p> -10- Let <tt>charT</tt> be <tt>decltype(fmt)::value_type</tt>.</p>
<p> [&hellip;] </p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3373" href="#3373">3373</a><sup><a href="https://cplusplus.github.io/LWG/issue3373">(i)</a></sup>. <tt>{to,from}_chars_result</tt> and <tt>format_to_n_result</tt> need the
 "we really mean what we say" wording</h3>
<p><b>Section:</b> 20.19.1 <a href="https://wg21.link/charconv.syn">[charconv.syn]</a>, 20.20.1 <a href="https://wg21.link/format.syn">[format.syn]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2020-01-16 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#charconv.syn">issues</a> in [charconv.syn].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
To ensure that <tt>to_chars_result</tt>, <tt>from_chars_result</tt>, and
<tt>format_to_n_result</tt> can be used in structured bindings, they need the
special wording we use to negate the general library permission to add private
data members and bases.
</p>

<p><i>[2020-02-01 Status set to Tentatively Ready after six positive votes on the reflector.]</i></p>



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

<ol>
<li><p>Add a paragraph at the end of 20.19.1 <a href="https://wg21.link/charconv.syn">[charconv.syn]</a> as follows:</p>

<blockquote>
<p>
-?- The types <tt>to_chars_result</tt> and <tt>from_chars_result</tt> have the
data members and special members specified above. They have no base classes or
members other than those specified.
</p>
</blockquote>
</li>

<li><p>Add a paragraph at the end of 20.20.1 <a href="https://wg21.link/format.syn">[format.syn]</a> as follows:</p>

<blockquote>
<p>
-1- The class template <tt>format_to_n_result</tt> has the template parameters,
data members, and special members specified above. It has no base classes or
members other than those specified.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3374" href="#3374">3374</a><sup><a href="https://cplusplus.github.io/LWG/issue3374">(i)</a></sup>. P0653 + P1006 should have made the other <tt>std::to_address</tt> overload <tt>constexpr</tt></h3>
<p><b>Section:</b> 20.10.4 <a href="https://wg21.link/pointer.conversion">[pointer.conversion]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2020-01-14 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
While reviewing some interactions with <a href="http://wg21.link/p0653">P0653</a> + 
<a href="http://wg21.link/p1006">P1006</a>, Billy discovered that one of the overloads was 
missing the <tt>constexpr</tt> tag. This might be a typo or a missed merge interaction between 
P0653 (which adds <tt>to_address</tt> with the pointer overload being <tt>constexpr</tt>) and 
P1006 (which makes <tt>pointer_traits::pointer_to constexpr</tt>). Mail was sent the LWG reflector, 
and Glen Fernandes, the author of P0653, indicates that this might have been an oversight.
</p>

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



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4842">N4842</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>
[&hellip;]
<i>// 20.10.4 <a href="https://wg21.link/pointer.conversion">[pointer.conversion]</a>, pointer conversion</i>
template&lt;class T&gt;
  constexpr T* to_address(T* p) noexcept;
template&lt;class Ptr&gt;
  <ins>constexpr</ins> auto to_address(const Ptr&amp; p) noexcept;
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Modify 20.10.4 <a href="https://wg21.link/pointer.conversion">[pointer.conversion]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Ptr&gt; <ins>constexpr</ins> auto to_address(const Ptr&amp; p) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> <tt>pointer_traits&lt;Ptr&gt;::to_address(p)</tt> if that expression is well-formed 
(see 20.10.3.3 <a href="https://wg21.link/pointer.traits.optmem">[pointer.traits.optmem]</a>), otherwise <tt>to_address(p.operator-&gt;())</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3375" href="#3375">3375</a><sup><a href="https://cplusplus.github.io/LWG/issue3375">(i)</a></sup>. <tt>decay</tt> in <tt>viewable_range</tt> should be <tt>remove_cvref</tt></h3>
<p><b>Section:</b> 24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-14 <b>Last modified:</b> 2020-02-13</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.refinements">active issues</a> in [range.refinements].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.refinements">issues</a> in [range.refinements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The viewable_range concept is defined in 24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a> as:
</p>
<blockquote>
<pre>
template&lt;class T&gt;
  concept viewable_range =
    range&lt;T&gt; &amp;&amp; (safe_range&lt;T&gt; || view&lt;decay_t&lt;T&gt;&gt;);
</pre>
</blockquote>
<p>
Since neither pointer types, array types, nor function types model <tt>view</tt>,
<tt>view&lt;decay_t&lt;T&gt;&gt;</tt> here could simplified to <tt>view&lt;remove_cvref_t&lt;T&gt;&gt;</tt>.
The use of <tt>decay_t</tt> is an artifact of the Ranges TS being based on C++14 which didn't have
<tt>remove_cvref_t</tt>. [Note that the proposed change is not purely editorial since the difference
is observable to subsumption.]
</p>

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


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

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

<blockquote>
<p>
-4- The <tt>viewable_range</tt> concept specifies the requirements of a <tt>range</tt> type that can be
converted to a <tt>view</tt> safely.
</p>
<pre>
template&lt;class T&gt;
  concept viewable_range =
    range&lt;T&gt; &amp;&amp; (safe_range&lt;T&gt; || view&lt;<del>decay_t</del><ins>remove_cvref</ins>&lt;T&gt;&gt;);
</pre>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-06 Casey provides a corrected P/R]</i></p>

<p>... in response to Jonathan's observation that <tt>remove_cvref&lt;T&gt;</tt> is both the wrong type <em>and</em> not what the
discussion argues for.</p>

<p><i>[2020-02 Status to Immediate on Thursday morning in Prague.]</i></p>



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

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

<blockquote>
<p>
-4- The <tt>viewable_range</tt> concept specifies the requirements of a <tt>range</tt> type that can be
converted to a <tt>view</tt> safely.
</p>
<pre>
template&lt;class T&gt;
  concept viewable_range =
    range&lt;T&gt; &amp;&amp; (safe_range&lt;T&gt; || view&lt;<del>decay_t</del><ins>remove_cvref_t</ins>&lt;T&gt;&gt;);
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3377" href="#3377">3377</a><sup><a href="https://cplusplus.github.io/LWG/issue3377">(i)</a></sup>. <tt>elements_view::iterator</tt> befriends a specialization of itself</h3>
<p><b>Section:</b> 24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-18 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The synopsis of the exposition-only class template <tt>elements_view::iterator</tt> in 
24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> includes the declaration "<tt>friend iterator&lt;!Const&gt;;</tt>". 
We typically don't depict such friend relationships in the Library specification, leaving the 
choice of how to implement access to private data from external sources to implementer magic. 
For consistency, we should strike this occurrence from <tt>elements_view::iterator</tt>.
</p>

<p><i>[2020-02-08 Status set to Tentatively Ready after ten 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 24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a>, class template <tt>elements_view::iterator</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class V, size_t N&gt;
  template&lt;bool Const&gt;
  class elements_view&lt;V, N&gt;::iterator { <i>// exposition only</i>
    using base_t = conditional_t&lt;Const, const V, V&gt;;
    <del>friend iterator&lt;!Const&gt;;</del>

    iterator_t&lt;base_t&gt; current_;
  public:
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3379" href="#3379">3379</a><sup><a href="https://cplusplus.github.io/LWG/issue3379">(i)</a></sup>. "<tt>safe</tt>" in several library names is misleading</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#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-21 <b>Last modified:</b> 2020-02-13</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Various WG21 members have commented that the use of "safe" in the names <tt>safe_range</tt>, 
<tt>enable_safe_range</tt>, <tt>safe_iterator_t</tt>, and <tt>safe_subrange_t</tt> to mean "fairly 
unlikely to produce dangling iterators" is inappropriate. The term "safe" has very strong 
connotations in some application domains, and these names don't intend such connotations. We 
could avoid confusion by changing these names to avoid the use of "safe". The Ranges Illuminati 
has deemed "borrowed" to be more appropriate: it reflects the fact that such ranges often 
"borrow" iterators from an adapted range which allows them to not be lifetime-bound to the 
adapting range.
</p>

<p><i>[2020-02-08 Issue Prioritization]</i></p>

<p>Priority to 1 after reflector discussion. This issue needs to be looked at by LEWG.</p>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Set to Immediate.
</p>


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

<ol>
<li>
<p>
Replace all occurrences of <tt>safe_range</tt>, <tt>enable_safe_range</tt>, <tt>safe_iterator_t</tt>, 
and <tt>safe_subrange_t</tt> in the working draft with <tt>borrowed_range</tt>, <tt>enable_borrowed_range</tt>, <tt>borrowed_iterator_t</tt>, and <tt>borrowed_subrange_t</tt>. 
</p>
</li>
</ol>





<hr>
<h3><a name="3380" href="#3380">3380</a><sup><a href="https://cplusplus.github.io/LWG/issue3380">(i)</a></sup>. <tt>common_type</tt> and comparison categories</h3>
<p><b>Section:</b> 20.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-23 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There are two paragraphs in the the definition of <tt>common_type</tt>:
</p>
<ul>
<li><p>Otherwise, if both <tt>D1</tt> and <tt>D2</tt> denote comparison category types 
(17.11.2.1 <a href="https://wg21.link/cmp.categories.pre">[cmp.categories.pre]</a>), let <tt>C</tt> denote the common comparison type 
(11.11.3 <a href="https://wg21.link/class.spaceship">[class.spaceship]</a>) of <tt>D1</tt> and <tt>D2</tt>.</p></li>
<li><p>Otherwise, if <tt>decay_t&lt;decltype(false ? declval&lt;D1&gt;() : declval&lt;D2&gt;())&gt;</tt> 
denotes a valid type, let <tt>C</tt> denote that type.</p></li>
</ul>
<p>
<a href="https://wg21.link/p1614r2">P1614R2</a> added the first bullet so that 
<tt>common_type_t&lt;strong_equality, T&gt;</tt> would be the same type as 
<tt>common_comparison_category_t&lt;strong_equality, T&gt;</tt>; other cases are correctly handled 
by the second (pre-existing) bullet. After application of <a href="https://wg21.link/p1959r0">P1959R0</a> 
in Belfast, <tt>std::strong_equality</tt> is no more. We can now strike the first bullet without 
changing the behavior of <tt>common_type</tt>.
</p>

<p><i>[2020-02-08 Status set to Tentatively Ready after seven positive votes on the reflector.]</i></p>



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

<ol>
<li><p>Modify 20.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a> as indicated:</p>

<blockquote>
<p>
-3- Note A: For the <tt>common_type</tt> trait applied to a template parameter pack <tt>T</tt> of types, 
the member <tt>type</tt> shall be either defined or not present as follows:
</p>
<ol style="list-style-type: none">
<li><p>(3.1) &mdash; [&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(3.3) &mdash; If <tt>sizeof...(T)</tt> is two, let the first and second types constituting <tt>T</tt> 
be denoted by <tt>T1</tt> and <tt>T2</tt>, respectively, and let <tt>D1</tt> and <tt>D2</tt> denote the 
same types as <tt>decay_t&lt;T1&gt;</tt> and <tt>decay_t&lt;T2&gt;</tt>, respectively.</p>
<ol style="list-style-type: none">
<li><p>(3.3.1) &mdash; If <tt>is_same_v&lt;T1, D1&gt;</tt> is <tt>false</tt> or <tt>is_same_v&lt;T2, D2&gt;</tt> 
is <tt>false</tt>, let <tt>C</tt> denote the same type, if any, as <tt>common_type_t&lt;D1, D2&gt;</tt>.</p></li>
<li><p>(3.3.2) &mdash; [<i>Note:</i> None of the following will apply if there is a specialization 
<tt>common_type&lt;D1, D2&gt;</tt>. &mdash; <i>end note</i>]</p></li>
<li><p><del>(3.3.3) &mdash; Otherwise, if both <tt>D1</tt> and <tt>D2</tt> denote comparison category types 
(17.11.2.1 <a href="https://wg21.link/cmp.categories.pre">[cmp.categories.pre]</a>), let <tt>C</tt> denote the common comparison type 
(11.11.3 <a href="https://wg21.link/class.spaceship">[class.spaceship]</a>) of <tt>D1</tt> and <tt>D2</tt>.</del></p></li>
<li><p>(3.3.4) &mdash; Otherwise, if</p>
<blockquote><pre>
decay_t&lt;decltype(false ? declval&lt;D1&gt;() : declval&lt;D2&gt;())>
</pre></blockquote>
<p>
denotes a valid type, let <tt>C</tt> denote that type.</p></li>
<li><p>(3.3.5) &mdash; [&hellip;]</p></li>
</ol>
</li>
<li><p>[&hellip;]</p></li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3381" href="#3381">3381</a><sup><a href="https://cplusplus.github.io/LWG/issue3381">(i)</a></sup>. <tt>begin</tt> and <tt>data</tt> must agree for <tt>contiguous_range</tt></h3>
<p><b>Section:</b> 24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2020-01-25 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.refinements">active issues</a> in [range.refinements].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.refinements">issues</a> in [range.refinements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of the <tt>contiguous_range</tt> concept in 24.4.5 <a href="https://wg21.link/range.refinements">[range.refinements]</a>/2 
requires that <tt>ranges::data(r)</tt> be valid for a <tt>contiguous_range r</tt>, but fails to 
impose the obvious semantic requirement that <tt>to_address(ranges::begin(r)) == ranges::data(r)</tt>. 
In other words, <tt>data</tt> and <tt>begin</tt> must agree so that <tt>[begin(r), end(r))</tt> and 
the counted range <tt>data(r) + [0, size(r))</tt> (this is the new "counted range" specification 
syntax per <a href="https://github.com/cplusplus/draft/issues/2932">working draft issue 2932</a>) denote 
the same sequence of elements.
</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

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

<blockquote>
<p>
-2- <tt>contiguous_range</tt> additionally requires that the <tt>ranges::data</tt> customization point 
(24.3.11 <a href="https://wg21.link/range.prim.data">[range.prim.data]</a>) is usable with the range.
</p>
<pre>
template&lt;class T&gt;
  concept contiguous_range =
    random_access_range&lt;T&gt; &amp;&amp; contiguous_iterator&lt;iterator_t&lt;T&gt;&gt; &amp;&amp;
    requires(T&amp; t) {
      { ranges::data(t) } -&gt; same_as&lt;add_pointer_t&lt;range_reference_t&lt;T&gt;&gt;&gt;;
    };
</pre>
<p>
<ins>-?- Given an expression <tt>t</tt> such that <tt>decltype((t))</tt> is <tt>T&amp;</tt>, <tt>T</tt> 
models <tt>contiguous_range</tt> only if <tt>(to_address(ranges::begin(t)) == ranges::data(t))</tt>.</ins>
<p/>
-3- The <tt>common_range</tt> concept [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3382" href="#3382">3382</a><sup><a href="https://cplusplus.github.io/LWG/issue3382">(i)</a></sup>. NTTP for <tt>pair</tt> and <tt>array</tt></h3>
<p><b>Section:</b> 20.4.2 <a href="https://wg21.link/pairs.pair">[pairs.pair]</a>, 22.3.7 <a href="https://wg21.link/array">[array]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2020-01-27 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We had <a href="https://github.com/cplusplus/nbballot/issues/235">this NB ballot issue</a>, to ensure that 
<tt>std::array</tt> could be a NTTP. But after <a href="https://wg21.link/p1907">P1907</a>, we still need 
some kind of wording to ensure that <tt>std::array</tt> (and also <tt>std::pair</tt>) have no extra 
private members or base classes.
<p/>
This is similar to LWG <a href="lwg-active.html#3373">3373</a> &mdash; maybe we just need to add:
</p>
<blockquote><p>
The class template <tt>pair</tt>/<tt>array</tt> has the data members specified above. It has no base 
classes or data members other than those specified.
</p></blockquote>

<p><i>[2020-02 Prioritized as P2 Monday morning in Prague]</i></p>


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

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

<blockquote>
<p>
-1- Constructors and member functions of <tt>pair</tt> do not throw exceptions unless one of the element-wise 
operations specified to be called for that operation throws an exception.
<p/>
-2- The defaulted move and copy constructor, respectively, of <tt>pair</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/>
-3- If <tt>(is_trivially_destructible_v&lt;T1&gt; &amp;&amp; is_trivially_destructible_v&lt;T2&gt;)</tt> 
is <tt>true</tt>, then the destructor of <tt>pair</tt> is trivial.
<p/>
<ins>-?- The class template <tt>pair</tt> has the data members specified above. It has no base classes or 
data members other than those specified.</ins>
</p>
</blockquote>
</li>

<li><p>Modify 22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a> as indicated:</p>

<blockquote>
<p>
-1- The header <tt>&lt;array&gt;</tt> defines a class template for storing fixed-size sequences of objects. 
An <tt>array</tt> is a contiguous container (22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>). An instance of 
<tt>array&lt;T, N&gt;</tt> stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() == N</tt> is 
an invariant.
<p/>
-2- An <tt>array</tt> is an aggregate (9.4.1 <a href="https://wg21.link/dcl.init.aggr">[dcl.init.aggr]</a>) that can be list-initialized with up 
to <tt>N</tt> elements whose types are convertible to <tt>T</tt>.
<p/>
-3- An <tt>array</tt> meets all of the requirements of a container and of a reversible container 
(22.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a>), except that a default constructed <tt>array</tt> object is not empty 
and that <tt>swap</tt> does not have constant complexity. An <tt>array</tt> meets some of the requirements 
of a sequence container (22.2.3 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a>). Descriptions are provided here only for
operations on <tt>array</tt> that are not described in one of these tables and for operations where there 
is additional semantic information.
<p/>
<ins>-?- The class template <tt>array</tt> has the data members specified in subclauses 
22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a> and 22.3.7.5 <a href="https://wg21.link/array.zero">[array.zero]</a>. It has no base classes or 
data members other than those specified.</ins>
<p/>
-4- [&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-13, Prague]</i></p>

<p>
Tim Song and Tomasz were trying to come up with general wording that could be reused for both <tt>pair</tt> and 
<tt>array</tt> (and other types). They suggest that if it should be in scope for C++20, it would be better to 
provide non-general wording for <tt>pair</tt> and <tt>array</tt> (that is easier to get right).
<p/>
For completeness (and future wording) the generalized wording is included. The definition of <i>structurally compatible with</i>:
</p>
<blockquote><p>
The type <code>T</code> is <em>structurally compatible with</em> <code><i>subs</i></code>, if for the values 
<code>t1</code> and <code>t2</code> of type <code>T</code>:
</p>
<ul>
 <li><p><code>T</code> is a structural type (13.2 <a href="https://wg21.link/temp.param">[temp.param]</a>) if the types of subobjects of <code>t1</code> 
 designated by <code><i>subs</i></code> are all structural types.</p></li>
 <li><p><code>t1</code> is template-argument-equivalent (13.6 <a href="https://wg21.link/temp.type">[temp.type]</a>) to <code>t2</code>, 
 if and only if, for each subject designed by  <code><i>subs</i></code>, the value of subobject 
 of <code>t1</code> is template-argument-equivalent to the value of the correponding subobject of 
 <code>t2</code>.</p></li>
</ul>
</blockquote>
<p>
Then changes for <code>array</code>/<code>pair</code> would then look like:
</p>
<blockquote>
<p>
<code>pair&lt;T, U&gt;</code> is structurally compatible (&lt;some-reference&gt;) with <code>first</code> and <code>second</code>.
<p/>
<code>array&lt;T, N&gt;</code> is structurally compatible with its elements (if any).
</p>
</blockquote>

<p><i>[2020-02 Status to Immediate on Friday morning in Prague.]</i></p>



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

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

<blockquote>
<p>
-1- Constructors and member functions of <tt>pair</tt> do not throw exceptions unless one of the element-wise 
operations specified to be called for that operation throws an exception.
<p/>
-2- The defaulted move and copy constructor, respectively, of <tt>pair</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/>
-3- If <tt>(is_trivially_destructible_v&lt;T1&gt; &amp;&amp; is_trivially_destructible_v&lt;T2&gt;)</tt> 
is <tt>true</tt>, then the destructor of <tt>pair</tt> is trivial.
<p/>
<ins>-?- <code>pair&lt;T, U&gt;</code> is a structural type (13.2 <a href="https://wg21.link/temp.param">[temp.param]</a>) if <code>T</code> 
and <code>U</code> are both structural types. Two values <code>p1</code> and <code>p2</code> of type 
<code>pair&lt;T, U&gt;</code> are template-argument-equivalent (13.6 <a href="https://wg21.link/temp.type">[temp.type]</a>) if and only if 
<code>p1.first</code> and <code>p2.first</code> are template-argument-equivalent and <code>p1.second</code> 
and <code>p2.second</code> are template-argument-equivalent.</ins>
</p>
</blockquote>
</li>

<li><p>Modify 22.3.7.1 <a href="https://wg21.link/array.overview">[array.overview]</a> as indicated:</p>

<blockquote>
<p>
-1- The header <tt>&lt;array&gt;</tt> defines a class template for storing fixed-size sequences of objects. 
An <tt>array</tt> is a contiguous container (22.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>). An instance of 
<tt>array&lt;T, N&gt;</tt> stores <tt>N</tt> elements of type <tt>T</tt>, so that <tt>size() == N</tt> is 
an invariant.
<p/>
-2- An <tt>array</tt> is an aggregate (9.4.1 <a href="https://wg21.link/dcl.init.aggr">[dcl.init.aggr]</a>) that can be list-initialized with up 
to <tt>N</tt> elements whose types are convertible to <tt>T</tt>.
<p/>
-3- An <tt>array</tt> meets all of the requirements of a container and of a reversible container 
(22.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a>), except that a default constructed <tt>array</tt> object is not empty 
and that <tt>swap</tt> does not have constant complexity. An <tt>array</tt> meets some of the requirements 
of a sequence container (22.2.3 <a href="https://wg21.link/sequence.reqmts">[sequence.reqmts]</a>). Descriptions are provided here only for
operations on <tt>array</tt> that are not described in one of these tables and for operations where there 
is additional semantic information.
<p/>
<ins>-?- <code>array&lt;T, N&gt;</code> is a structural type (13.2 <a href="https://wg21.link/temp.param">[temp.param]</a>) if <code>T</code> 
is a structural type. Two values <code>a1</code> and <code>a2</code> of type <code>array&lt;T, N&gt;</code> 
are template-argument-equivalent (13.6 <a href="https://wg21.link/temp.type">[temp.type]</a>) if and only if each pair of corresponding 
elements in <code>a1</code> and <code>a2</code> are template-argument-equivalent.</ins>
<p/>
-4- [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3383" href="#3383">3383</a><sup><a href="https://cplusplus.github.io/LWG/issue3383">(i)</a></sup>. &sect;[time.zone.leap.nonmembers] <tt>sys_seconds</tt> should be replaced with <tt>seconds</tt></h3>
<p><b>Section:</b> 27.11.8.3 <a href="https://wg21.link/time.zone.leap.nonmembers">[time.zone.leap.nonmembers]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jiang An <b>Opened:</b> 2020-01-30 <b>Last modified:</b> 2020-02-12</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In <a href="https://wg21.link/n4849">N4849</a> 27.11.8.3 <a href="https://wg21.link/time.zone.leap.nonmembers">[time.zone.leap.nonmembers]</a>/12, the type 
template parameter <tt>Duration</tt> is constrained by <tt>three_way_comparable_with&lt;sys_seconds&gt;</tt>. 
However, since <tt>std::chrono::sys_seconds</tt> is a time point type and <tt>Duration</tt> must be a 
duration type, they can never be compared directly via <tt>operator&lt;=&gt;</tt>.
<p/>
I guess that the actual intent is comparing <tt>Duration</tt> with the duration type of 
<tt>std::chrono::sys_seconds</tt>, i.e. <tt>std::chrono::seconds</tt>. And thus <tt>sys_seconds</tt> 
should be replaced with <tt>seconds</tt> here.
</p>

<p><i>[2020-02 Prioritized as P1 Monday morning in Prague]</i></p>


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

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

<blockquote>
<pre>
namespace std {
  [&hellip;]
  namespace chrono {
    [&hellip;]
    template&lt;three_way_comparable_with&lt;<del>sys_</del>seconds&gt; Duration&gt;
      auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y);
    [&hellip;]
  }
  [&hellip;]
}
</pre>
<blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;three_way_comparable_with&lt;<del>sys_</del>seconds&gt; Duration&gt;
  constexpr auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y) noexcept;
</pre>
<blockquote>
<p>
-12- <i>Returns:</i> <tt>x.date() &lt;=&gt; y</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-10, Prague; Howard suggests alternative wording]</i></p>

<p>
The below shown alternative wording does more directly describe the constrained code (by comparing 
<tt>time_point</tt>s), even though in the very end the code specifying the effects finally goes down 
to actually return <tt>x.date().time_since_epoch() &lt;=&gt; y.time_since_epoch()</tt> (thus comparing 
<tt>duration</tt>s).
</p>

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

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

<blockquote class="note">
<p>
The synopsis does provide an additional drive-by fix to eliminate the mismatch of the <tt>constexpr</tt>
and <tt>noexcept</tt> in declaration and prototype specification.
</p>
</blockquote>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  namespace chrono {
    [&hellip;]
    template&lt;<del>three_way_comparable_with&lt;sys_seconds&gt;</del><ins>class</ins> Duration&gt;
      <ins>requires three_way_comparable_with&lt;sys_seconds, sys_time&lt;Duration&gt;&gt;</ins>
        <ins>constexpr</ins> auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y) <ins>noexcept</ins>;
    [&hellip;]
  }
  [&hellip;]
}
</pre>
<blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;<del>three_way_comparable_with&lt;sys_seconds&gt;</del><ins>class</ins> Duration&gt;
  <ins>requires three_way_comparable_with&lt;sys_seconds, sys_time&lt;Duration&gt;&gt;</ins>
    constexpr auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y) noexcept;
</pre>
<blockquote>
<p>
-12- <i>Returns:</i> <tt>x.date() &lt;=&gt; y</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2020-02-11, Prague; Daniel suggests alternative wording]</i></p>

<p>
During today's LWG discussion of this issue the observation was made that there also exists a 
mismatch regarding the <tt>noexcept</tt> specifier for both declarations, but for this second deviation
a corresponding change does <em>not</em> seem to be a good drive-by fix candidate, because we have a
function template here that allows supporting user-defined types, whose comparison may throw (Note 
that the corresponding <tt>operator&lt;=&gt;</tt> or other comparison function declarations of the 
<tt>duration</tt> and <tt>time_point</tt> templates are <em>not</em> specified as <tt>noexcept</tt> 
function templates). The revised wording below does therefore intentionally <em>not</em> change the
currently existing <tt>noexcept</tt>-specifier mismatch, but a separate issue should instead be
opened for the general <tt>noexcept</tt>-specifier mismatches for all comparison function templates
of <tt>std::chrono::leap</tt>. Daniel has volunteered to take care for this issue.
</p>

<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</i></p>



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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The synopsis does provide an additional drive-by fix to eliminate the mismatch of the 
<tt>constexpr</tt> in declaration and prototype specification, but does <em>not</em> so for a similar
mismatch of the exception-specifications of both declarations.]
</p>
</blockquote>

<blockquote>
<pre>
namespace std {
  [&hellip;]
  namespace chrono {
    [&hellip;]
    template&lt;<del>three_way_comparable_with&lt;sys_seconds&gt;</del><ins>class</ins> Duration&gt;
      <ins>requires three_way_comparable_with&lt;sys_seconds, sys_time&lt;Duration&gt;&gt;</ins>
        <ins>constexpr</ins> auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y);
    [&hellip;]
  }
  [&hellip;]
}
</pre>
<blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<pre>
template&lt;<del>three_way_comparable_with&lt;sys_seconds&gt;</del><ins>class</ins> Duration&gt;
  <ins>requires three_way_comparable_with&lt;sys_seconds, sys_time&lt;Duration&gt;&gt;</ins>
    constexpr auto operator&lt;=&gt;(const leap&amp; x, const sys_time&lt;Duration&gt;&amp; y) noexcept;
</pre>
<blockquote>
<p>
-12- <i>Returns:</i> <tt>x.date() &lt;=&gt; y</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3384" href="#3384">3384</a><sup><a href="https://cplusplus.github.io/LWG/issue3384">(i)</a></sup>. <tt>transform_view::<i>sentinel</i></tt> has an incorrect <tt>operator-</tt></h3>
<p><b>Section:</b> 24.7.5.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2020-01-31 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<ol>
<li><p><tt>transform_view::<i>iterator</i></tt> has an exposition-only member <tt><i>current_</i></tt> 
(24.7.5.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>)</p></li>
<li><p><tt>transform_view::<i>sentinel</i></tt> has an exposition-only member <tt><i>end_</i></tt>
(24.7.5.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a>)</p></li>
<li><p>at 24.7.5.4 <a href="https://wg21.link/range.transform.sentinel">[range.transform.sentinel]</a>/6 we have:</p></li>
</ol>
<pre>
friend constexpr range_difference_t&lt;<i>Base</i>&gt;
  operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;Const&gt;&amp; x)
    requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;;
</pre>
<blockquote><p>
<i>Effects:</i> Equivalent to: <tt>return x.<i>end_</i> - y.<i>current_</i>;</tt>
</p></blockquote>
<p>
<tt>x</tt> is an <tt><i>iterator</i></tt>, so it has <tt><i>current_</i></tt>, not <tt><i>end_</i></tt>. 
<tt>y</tt> is a <tt><i>sentinel</i></tt>, so it has <tt><i>end_</i></tt>, not <tt><i>current_</i></tt>.</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

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

<blockquote>
<pre>
friend constexpr range_difference_t&lt;<i>Base</i>&gt;
  operator-(const <i>sentinel</i>&amp; y, const <i>iterator</i>&lt;Const&gt;&amp; x)
    requires sized_sentinel_for&lt;sentinel_t&lt;<i>Base</i>&gt;, iterator_t&lt;<i>Base</i>&gt;&gt;;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to: <tt>return <del>x</del><ins>y</ins>.<i>end_</i> - <del>y</del><ins>x</ins>.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3385" href="#3385">3385</a><sup><a href="https://cplusplus.github.io/LWG/issue3385">(i)</a></sup>. <tt>common_iterator</tt> is not sufficiently constrained for non-copyable iterators</h3>
<p><b>Section:</b> 23.5.4.1 <a href="https://wg21.link/common.iterator">[common.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Corentin Jabot <b>Opened:</b> 2020-01-31 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We don't actually specify anywhere that non-copyable iterators do not have a <tt>common_iterator</tt> 
(and it would make little sense for them to as algorithms dealing with C++17 iterators are not expecting 
non-copyable things) As it stands <tt>common_iterator</tt> can be created from move only iterator but 
are then non-copyable themselves. <a href="https://wg21.link/p1862">P1862</a> already constrains 
<tt>common_view</tt> in a similar fashion</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

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

<blockquote>
<pre>
namespace std {
  [&hellip;]
  <i>// 23.5.4 <a href="https://wg21.link/iterators.common">[iterators.common]</a>, common iterators</i>
  template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
    requires (!same_as&lt;I, S&gt; <ins>&amp;&amp; copyable&lt;I&gt;</ins>)
      class common_iterator;
  [&hellip;]
}
</pre>
</blockquote>
</li>

<li><p>Modify 23.5.4.1 <a href="https://wg21.link/common.iterator">[common.iterator]</a>, class template <tt>common_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  template&lt;input_or_output_iterator I, sentinel_for&lt;I&gt; S&gt;
    requires (!same_as&lt;I, S&gt; <ins>&amp;&amp; copyable&lt;I&gt;</ins>)
  class common_iterator {
  public:
    [&hellip;]
  };
  [&hellip;]
}
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3387" href="#3387">3387</a><sup><a href="https://cplusplus.github.io/LWG/issue3387">(i)</a></sup>. &sect;[range.reverse.view] <tt>reverse_view&lt;V&gt;</tt> unintentionally requires <tt>range&lt;const V&gt;</tt></h3>
<p><b>Section:</b> 24.7.14.2 <a href="https://wg21.link/range.reverse.view">[range.reverse.view]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2020-02-04 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>reverse_view&lt;V&gt;</tt> requires <tt>bidirectional_range&lt;V&gt;</tt>, but not <tt>range&lt;const V&gt;</tt>, 
which means that <tt>iterator_t&lt;const V&gt;</tt> might be an invalid type. The return types of the 
<tt>begin() const</tt> and <tt>end() const</tt> overloads make use of <tt>iterator_t&lt;const V&gt;</tt> 
in a non-SFINAE context, which means that instantiating <tt>reverse_view&lt;X&gt;</tt> is ill-formed unless 
<tt>range&lt;const X&gt;</tt> is satisfied.
<p/>
Code like <tt>x | views::filter(p) | views::reverse</tt> fails to compile because 
<tt>const filter_view&lt;&hellip;&gt;</tt> does not model <tt>range</tt>, so 
<tt>iterator_t&lt;const filter_view&lt;&hellip;&gt;&gt;</tt> is invalid.
<p/>
Either <tt>range&lt;const V&gt;</tt> needs to be in the class' <tt>requires</tt>-clause, or the return types 
of the <tt>const</tt>-qualified <tt>begin()</tt> and <tt>end()</tt> need to delay use of 
<tt>iterator_t&lt;const V&gt;</tt> until <tt>range&lt;const V&gt;</tt> is known to be satisfied.
<p/>
Giving these overloads an <tt>auto</tt> return type means the type is determined when the member is called. 
The constraint <tt>common_range&lt;const V&gt;</tt> appropriately restricts the selection of these overloads, 
so they can only be called when the type is valid. This is what <tt>cmcstl2</tt> does. <tt>range-v3</tt> 
makes the <tt>begin() const</tt> and <tt>end() const</tt> members into function templates, so that they 
are SFINAE contexts.
</p>

This is related to <a href="lwg-active.html#3347">3347</a>.
<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

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

<blockquote>
<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; {
    [&hellip;]
    constexpr reverse_iterator&lt;iterator_t&lt;V&gt;&gt; begin();
    constexpr reverse_iterator&lt;iterator_t&lt;V&gt;&gt; begin() requires common_range&lt;V&gt;;
    constexpr <del>reverse_iterator&lt;iterator_t&lt;const V&gt;&gt;</del><ins>auto</ins> begin() const
      requires common_range&lt;const V&gt;;  
    
    constexpr reverse_iterator&lt;iterator_t&lt;V&gt;&gt; end();
    constexpr <del>reverse_iterator&lt;iterator_t&lt;const V&gt;&gt;</del><ins>auto</ins> end() const
      requires common_range&lt;const V&gt;;  
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
</blockquote>
<blockquote>
<pre>
constexpr reverse_iterator&lt;iterator_t&lt;V&gt;&gt; begin() requires common_range&lt;V&gt;;
constexpr <del>reverse_iterator&lt;iterator_t&lt;const V&gt;&gt;</del><ins>auto</ins> begin() const
  requires common_range&lt;const V&gt;;
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> Equivalent to: <tt>return make_reverse_iterator(ranges::end(base_));</tt>
</p>
</blockquote>
<pre>
constexpr reverse_iterator&lt;iterator_t&lt;V&gt;&gt; end();
constexpr <del>reverse_iterator&lt;iterator_t&lt;const V&gt;&gt;</del><ins>auto</ins> end() const
  requires common_range&lt;const V&gt;;
</pre>
<blockquote>
<p>
-6- <i>Effects:</i> Equivalent to: <tt>return make_reverse_iterator(ranges::begin(base_));</tt>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3388" href="#3388">3388</a><sup><a href="https://cplusplus.github.io/LWG/issue3388">(i)</a></sup>. <tt>view</tt> iterator types have ill-formed <tt>&lt;=&gt;</tt> operators</h3>
<p><b>Section:</b> 24.6.3.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a>, 24.7.5.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a>, 24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2020-02-07 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.iota.iterator">active issues</a> in [range.iota.iterator].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.iota.iterator">issues</a> in [range.iota.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
24.6.3.3 <a href="https://wg21.link/range.iota.iterator">[range.iota.iterator]</a> and 24.7.5.3 <a href="https://wg21.link/range.transform.iterator">[range.transform.iterator]</a> and 
24.7.15.3 <a href="https://wg21.link/range.elements.iterator">[range.elements.iterator]</a> all declare <tt>operator&lt;=&gt;</tt> similar to this:
</p>
<blockquote><pre>
friend constexpr compare_three_way_result_t&lt;W&gt; operator&lt;=&gt;(
    const iterator&amp; x, const iterator&amp; y)
  requires totally_ordered&lt;W&gt; &amp;&amp; three_way_comparable&lt;W&gt;;
</pre></blockquote>
<p>
Similar to issue <a href="lwg-active.html#3347">3347</a> and issue <a href="lwg-active.html#3387">3387</a>, this is ill-formed if 
<tt>three_way_comparable&lt;W&gt;</tt> is not satisfied, because <tt>compare_three_way_result_t&lt;W&gt;</tt> 
is invalid. This declaration is instantiated when the enclosing iterator type is instantiated, making 
any use of <tt>iota_view&lt;W, B&gt;::iterator</tt> ill-formed when <tt>three_way_comparable&lt;W&gt;</tt> 
is not satisfied.
<p/>
We can either add an exposition-only <tt><i>safe-compare-three-way-result-t</i></tt> alias that denotes 
<tt>void</tt> or <tt>std::nonesuch</tt> for spaceship-less types, so the declaration is valid (and then 
disabled by the constraints), or simply make them return <tt>auto</tt>.
</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4849">N4849</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;::<i>iterator</i> {
    [&hellip;]
    friend constexpr <del>compare_three_way_result_t&lt;W&gt;</del><ins>auto</ins> operator&lt;=&gt;(
        const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
      requires totally_ordered&lt;W&gt; &amp;&amp; three_way_comparable&lt;W&gt;;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
</blockquote>
<blockquote>
<pre>
friend constexpr <del>compare_three_way_result_t&lt;W&gt;</del><ins>auto</ins>
  operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires totally_ordered&lt;W&gt; &amp;&amp; three_way_comparable&lt;W&gt;;
</pre>
<blockquote>
<p>
-19- <i>Effects:</i> Equivalent to: <tt>return x.value_ &lt;=&gt; y.value_;</tt>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;class V, class F&gt;
  template&lt;bool Const&gt;
  class transform_view&lt;V, F&gt;::<i>iterator</i> {
    [&hellip;]
    friend constexpr <del>compare_three_way_result_t&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del><ins>auto</ins> 
      operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
        requires random_access_range&lt;<i>Base</i>&gt; &amp;&amp; three_way_comparable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
</blockquote>
<blockquote>
<pre>
friend constexpr <del>compare_three_way_result_t&lt;iterator_t&lt;<i>Base</i>&gt;&gt;</del><ins>auto</ins>
  operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>Base</i>&gt; &amp;&amp; three_way_comparable&lt;iterator_t&lt;<i>Base</i>&gt;&gt;;
</pre>
<blockquote>
<p>
-19- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> &lt;=&gt; y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>

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

<blockquote>
<blockquote>
<pre>
namespace std::ranges {
  template&lt;class V, size_t N&gt;
  template&lt;bool Const&gt;
  class elements_view&lt;V, N&gt;::<i>iterator</i> {
    [&hellip;]
    friend constexpr <del>compare_three_way_result_t&lt;iterator_t&lt;<i>base-t</i>&gt;&gt;</del><ins>auto</ins> 
      operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
        requires random_access_range&lt;<i>base-t</i>&gt; &amp;&amp; three_way_comparable&lt;iterator_t&lt;<i>base-t</i>&gt;&gt;;
    [&hellip;]
  };
  [&hellip;]
}
</pre>
[&hellip;]
</blockquote>
<blockquote>
<pre>
friend constexpr <del>compare_three_way_result_t&lt;iterator_t&lt;<i>base-t</i>&gt;&gt;</del><ins>auto</ins>
  operator&lt;=&gt;(const <i>iterator</i>&amp; x, const <i>iterator</i>&amp; y)
    requires random_access_range&lt;<i>base-t</i>&gt; &amp;&amp; three_way_comparable&lt;iterator_t&lt;<i>base-t</i>&gt;&gt;;
</pre>
<blockquote>
<p>
-18- <i>Effects:</i> Equivalent to: <tt>return x.<i>current_</i> &lt;=&gt; y.<i>current_</i>;</tt>
</p>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3389" href="#3389">3389</a><sup><a href="https://cplusplus.github.io/LWG/issue3389">(i)</a></sup>. A move-only iterator still does not have a <tt>counted_iterator</tt></h3>
<p><b>Section:</b> 23.5.6.2 <a href="https://wg21.link/counted.iter.const">[counted.iter.const]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2020-02-07 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p1207r4">P1207R4</a> ("Movability of single-pass iterators") 
introduces the notion of a move-only non-forward iterator and makes some changes to 
the iterator adaptor <tt>counted_iterator</tt> in order to support move-only iterators.
<p/>
The problem is that the constructor of <tt>counted_iterator</tt> (23.5.6.2 <a href="https://wg21.link/counted.iter.const">[counted.iter.const]</a> p2) 
accepting such an iterator is specified as "Initializes <tt>current</tt> with <tt>i</tt>" 
which would attempt copy-constructing <tt>current</tt> from <tt>i</tt> instead of move-constructing it.
</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

<ol>
<li><p>Modify 23.5.6.2 <a href="https://wg21.link/counted.iter.const">[counted.iter.const]</a> as indicated:</p>

<blockquote>
<pre>
constexpr counted_iterator(I i, iter_difference_t&lt;I&gt; n);
</pre>
<blockquote>
<p>
-1- <i>Preconditions:</i> <tt>n &gt;= 0</tt>.
<p/>
-2- <i>Effects:</i> Initializes <tt>current</tt> with <tt><ins>std::move(</ins>i<ins>)</ins></tt> 
and <tt>length</tt> with <tt>n</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3390" href="#3390">3390</a><sup><a href="https://cplusplus.github.io/LWG/issue3390">(i)</a></sup>. <tt>make_move_iterator()</tt> cannot be used to construct a <tt>move_iterator</tt> for a
move-only iterator</h3>
<p><b>Section:</b> 23.5.3.8 <a href="https://wg21.link/move.iter.nonmember">[move.iter.nonmember]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Patrick Palka <b>Opened:</b> 2020-02-07 <b>Last modified:</b> 2020-02-10</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#move.iter.nonmember">active issues</a> in [move.iter.nonmember].</p>
<p><b>View all other</b> <a href="lwg-index.html#move.iter.nonmember">issues</a> in [move.iter.nonmember].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="https://wg21.link/p1207r4">P1207R4</a> ("Movability of single-pass iterators") 
introduces the notion of a move-only non-forward iterator and makes some changes to 
the existing specification to realize that support.
<p/>
The problem is that the specification of <tt>make_move_iterator()</tt> provided in 
23.5.3.8 <a href="https://wg21.link/move.iter.nonmember">[move.iter.nonmember]</a> p6 does attempt to construct a
<tt>move_iterator&lt;Iterator&gt;</tt> with an lvalue of <tt>i</tt> instead
of an rvalue, having the effect of copying it instead of moving it, thus preventing
to accept move-only iterators.
</p>

<p><i>[2020-02 Prioritized as IMMEDIATE Monday morning in Prague]</i></p>



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

<ol>
<li><p>Modify 23.5.3.8 <a href="https://wg21.link/move.iter.nonmember">[move.iter.nonmember]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Iterator&gt;
constexpr move_iterator&lt;Iterator&gt; make_move_iterator(Iterator i);
</pre>
<blockquote>
<p>
-6- <i>Returns:</i> <tt>move_iterator&lt;Iterator&gt;(<ins>std::move(</ins>i<ins>)</ins>)</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3393" href="#3393">3393</a><sup><a href="https://cplusplus.github.io/LWG/issue3393">(i)</a></sup>. Missing/incorrect feature test macro for coroutines</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#Immediate">Immediate</a>
 <b>Submitter:</b> Barry Revzin <b>Opened:</b> 2020-01-25 <b>Last modified:</b> 2020-02-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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We have a policy, established in <a href="https://wg21.link/p1353">P1353</a> (and needing to be added to SD-6):
<p/>
In some cases a feature requires two macros, one for the language and one for the library. For example, the 
library does not want to define its three-way comparison operations unless the compiler supports the feature.
<p/>
For end-users, it is suggested that they test only the library macro, as that will only be true if the 
language macro is also true. As a result, the language macros contain "impl" to distinguish them from the 
more general version that is expected to be set by the library.
That paper added two papers of macros: one for <tt>&lt;=&gt;</tt> and one for destroying <tt>delete</tt>. 
We have a third such example in coroutines: there is library machinery that needs to be provided only when 
the compiler has language support for it, and the end user should just check the library macro.
</p>

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

<ol>
<li><p>Modify 15.11 <a href="https://wg21.link/cpp.predefined">[cpp.predefined]</a>, Table [tab:cpp.predefined.ft], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 18: Feature-test macros [tab:cpp.predefined.ft]</caption>
<tr align="center">
<th>Macro name</th>
<th>Value</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>__cpp<ins>_impl</ins>_coroutines</tt>
</td>
<td>
<tt>201902L</tt>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
</blockquote>

</li>

<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_constexpr_vector    201907L <i>// also in &lt;vector&gt;</i>
<ins>#define __cpp_lib_coroutines          201902L <i>// also in &lt;coroutine&gt;</i></ins>
#define __cpp_lib_destroying_delete   201806L <i>// also in &lt;new&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-11, Prague]</i></p>

<p>
LWG observed that the naming suggestion didn't follow naming conventions of SG-10 because of the plural form
<tt>corountines</tt>. The submitter agreed with that complaint, so the revised wording uses now the singular
form.
</p>

<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</i></p>



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

<ol>
<li><p>Modify 15.11 <a href="https://wg21.link/cpp.predefined">[cpp.predefined]</a>, Table [tab:cpp.predefined.ft], as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 18: Feature-test macros [tab:cpp.predefined.ft]</caption>
<tr align="center">
<th>Macro name</th>
<th>Value</th>
</tr> 

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

<tr>
<td>
<tt>__cpp<ins>_impl</ins>_coroutine<del>s</del></tt>
</td>
<td>
<tt>201902L</tt>
</td>
</tr>

<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>

</table>
</blockquote>

</li>

<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_constexpr_vector    201907L <i>// also in &lt;vector&gt;</i>
<ins>#define __cpp_lib_coroutine           201902L <i>// also in &lt;coroutine&gt;</i></ins>
#define __cpp_lib_destroying_delete   201806L <i>// also in &lt;new&gt;</i>
[&hellip;]
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3395" href="#3395">3395</a><sup><a href="https://cplusplus.github.io/LWG/issue3395">(i)</a></sup>. Definition for three-way comparison needs to be updated (US 152)</h3>
<p><b>Section:</b> 16.3.4 <a href="https://wg21.link/defns.comparison">[defns.comparison]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jeff Garland <b>Opened:</b> 2020-02-10 <b>Last modified:</b> 2020-02-12</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/151">US 152</a></b></p>
<p>
This definition in 16.3.4 <a href="https://wg21.link/defns.comparison">[defns.comparison]</a> should be updated to accommodate the new 3-way comparison operator 
(7.6.8 <a href="https://wg21.link/expr.spaceship">[expr.spaceship]</a>) as well.
</p>
<p><i>[2020-02 Moved to Immediate on Tuesday in Prague.]</i></p>



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

<ol>
<li><p>Modify 16.3.4 <a href="https://wg21.link/defns.comparison">[defns.comparison]</a> as indicated:</p>

<blockquote>
<p>
<b>comparison function</b>
<p/>
operator function (12.6 <a href="https://wg21.link/over.oper">[over.oper]</a>) for any of the equality (7.6.10 <a href="https://wg21.link/expr.eq">[expr.eq]</a>)<ins>,</ins> 
<del>or</del> relational (7.6.9 <a href="https://wg21.link/expr.rel">[expr.rel]</a>)<ins>, or three-way comparison 
(7.6.8 <a href="https://wg21.link/expr.spaceship">[expr.spaceship]</a>)</ins> operators
</p>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3396" href="#3396">3396</a><sup><a href="https://cplusplus.github.io/LWG/issue3396">(i)</a></sup>. Clarify point of reference for <tt>source_location::current()</tt> (DE 169)</h3>
<p><b>Section:</b> 17.8.2.1 <a href="https://wg21.link/support.srcloc.cons">[support.srcloc.cons]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2020-02-13 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses <a href="https://github.com/cplusplus/nbballot/issues/167">DE 169</a></b></p>
<p>
The expectation of the note that a default argument expression
involving current() causes a source_location to be constructed
that refers to the site of a function call where that default
argument is needed has no basis in normative text.
In particular, 9.2.3.6 paragraph 5 seems to imply that the
name "current" and its semantics are bound where it appears
lexically in the function declaration.
<p/>
Proposed change:
<p/>
Add normative text to express the desired semantics.
</p>

<p><i>[2020-02 Moved to Immediate on Thursday afternoon in Prague.]</i></p>



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

<ol>
<li><p>Modify 17.8.2.1 <a href="https://wg21.link/support.srcloc.cons">[support.srcloc.cons]</a> as indicated:</p>

<blockquote>
<pre>
static consteval source_location current() noexcept;
</pre>
<blockquote>
<p>
-1- [&hellip;]
<p/>
-2- <i>Remarks:</i> <del>When a default member initializer is used to initialize a non-static data member, any calls to
<tt>current</tt></del><ins>Any call to <tt>current</tt> that appears as a default member initializer (11.4 <a href="https://wg21.link/class.mem">[class.mem]</a>), 
or as a subexpression thereof,</ins> should correspond to the location of the constructor <ins>definition</ins> or 
aggregate initialization that <del>initializes the member</del><ins>uses the default member initializer</ins>. 
<ins>Any call to <tt>current</tt> that appears as a default argument (9.3.3.6 <a href="https://wg21.link/dcl.fct.default">[dcl.fct.default]</a>), or as a subexpression thereof, 
should correspond to the location of the invocation of the function that uses the default argument (7.6.1.2 <a href="https://wg21.link/expr.call">[expr.call]</a>).</ins>
<p/>
<del>-3- [<i>Note:</i> When used as a default argument (9.3.3.6 <a href="https://wg21.link/dcl.fct.default">[dcl.fct.default]</a>), the value of the 
<tt>source_location</tt> will be the location of the call to <tt>current</tt> at the call site. &mdash; <i>end note</i>]</del>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3397" href="#3397">3397</a><sup><a href="https://cplusplus.github.io/LWG/issue3397">(i)</a></sup>. <tt>ranges::basic_istream_view::iterator</tt> should not provide <tt>iterator_category</tt></h3>
<p><b>Section:</b> 24.6.4.3 <a href="https://wg21.link/range.istream.iterator">[range.istream.iterator]</a> <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2020-02-13 <b>Last modified:</b> 2020-02-14</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#range.istream.iterator">active issues</a> in [range.istream.iterator].</p>
<p><b>View all other</b> <a href="lwg-index.html#range.istream.iterator">issues</a> in [range.istream.iterator].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>ranges::basic_istream_view::iterator</tt> is a move-only type, and as such it does not meets the 
<i>Cpp17</i> iterator requirements, yet it does provides <tt>iterator_category</tt> (intended to be used for 
<i>Cpp17</i> iterators). We should provide <tt>iterator_concept</tt> instead.
</p>

<p><i>[2020-02 Status to Immediate on Thursday night in Prague.]</i></p>



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

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

<blockquote>
<pre>
namespace std::ranges {
  template&lt;class Val, class CharT, class Traits&gt;
  class basic_istream_view&lt;Val, CharT, Traits&gt;::<i>iterator</i> { <i>// exposition only</i>
  public:
    using <del>iterator_category</del><ins>iterator_concept</ins> = input_iterator_tag;
    using difference_type = ptrdiff_t;
    using value_type = Val;

    <i>iterator</i>() = default;
    [&hellip;]
  };
}
</pre>
<blockquote>
<p>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3398" href="#3398">3398</a><sup><a href="https://cplusplus.github.io/LWG/issue3398">(i)</a></sup>. <tt>tuple_element_t</tt> is also wrong for <tt>const subrange</tt></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#Immediate">Immediate</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-02-13 <b>Last modified:</b> 2020-02-14</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#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As currently specified, it uses the <i>cv</i>-qualified partial specialization, which incorrectly
adds <i>cv</i>-qualification to the element type.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<blockquote class="note">
<p>This wording is relative to <a href="http://wg21.link/n4849">N4849</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>
[&hellip;]
namespace std {
  namespace views = ranges::views;

  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_size&lt;ranges::subrange&lt;I, S, K&gt;&gt;
    : integral_constant&lt;size_t, 2&gt; {};
  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_element&lt;0, ranges::subrange&lt;I, S, K&gt;&gt; {
    using type = I;
  };
  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_element&lt;1, ranges::subrange&lt;I, S, K&gt;&gt; {
    using type = S;
  };
  <ins>template&lt;class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;0, const ranges::subrange&lt;I, S, K&gt;&gt; {</ins>
    <ins>using type = I;</ins>
  <ins>};</ins>
  <ins>template&lt;class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;1, const ranges::subrange&lt;I, S, K&gt;&gt; {</ins>
    <ins>using type = S;</ins>
  <ins>};</ins>
}
</pre>
</blockquote>
</li>

<li><p>Add the following wording to Annex D:</p>

<blockquote>
<p>
<ins><b>D.? Deprecated <tt>subrange</tt> tuple interface [depr.ranges.syn]</b></ins>
<p/>
<ins>1 The header <tt>&lt;ranges&gt;</tt> (24.2 <a href="https://wg21.link/ranges.syn">[ranges.syn]</a>) has the following additions:</ins>
</p>
<blockquote><pre>
<ins>namespace std {</ins>
  <ins>template&lt;size_t X, class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;X, volatile ranges::subrange&lt;I, S, K&gt;&gt; {};</ins>
  <ins>template&lt;size_t X, class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;X, const volatile ranges::subrange&lt;I, S, K&gt;&gt; {};</ins>
<ins>}</ins>
</pre></blockquote>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2020-02-14, Prague]</i></p>

<p>
LWG decided to remove the volatile support, we shouldn't give the impression to support an  
idiom that wouldn't work.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/n4849">N4849</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>
[&hellip;]
namespace std {
  namespace views = ranges::views;

  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_size&lt;ranges::subrange&lt;I, S, K&gt;&gt;
    : integral_constant&lt;size_t, 2&gt; {};
  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_element&lt;0, ranges::subrange&lt;I, S, K&gt;&gt; {
    using type = I;
  };
  template&lt;class I, class S, ranges::subrange_kind K&gt;
  struct tuple_element&lt;1, ranges::subrange&lt;I, S, K&gt;&gt; {
    using type = S;
  };
  <ins>template&lt;class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;0, const ranges::subrange&lt;I, S, K&gt;&gt; {</ins>
    <ins>using type = I;</ins>
  <ins>};</ins>
  <ins>template&lt;class I, class S, ranges::subrange_kind K&gt;</ins>
  <ins>struct tuple_element&lt;1, const ranges::subrange&lt;I, S, K&gt;&gt; {</ins>
    <ins>using type = S;</ins>
  <ins>};</ins>
}
</pre>
</blockquote>
</li>

</ol>




</body>
</html>
