<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<meta charset="utf-8">
<title>C++ Standard Library Issues to be moved in Belfast</title>
<style type="text/css">
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note
  {
    background-color:#E0E0E0;
    padding-left: 15px;
    padding-right: 15px;
    padding-top: 1px;
    padding-bottom: 1px;
  }
  ins {background-color:#A0FFA0}
  del {background-color:#FFA0A0}
  table {border-collapse: collapse;}
</style>
</head>
<body>
<h1>C++ Standard Library Issues to be moved in Belfast</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P1917R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2019-10-07 at 02:37:36 UTC</p>
</td>
</tr>
<tr>
<td align="left">Project:</td>
<td align="left">Programming Language C++</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Marshall Clow &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2>Ready Issues</h2>
<hr>
<h3><a name="3070" href="#3070">3070</a><sup><a href="https://cplusplus.github.io/LWG/issue3070">(i)</a></sup>. <tt>path::lexically_relative</tt> causes surprising results if a filename can also be a 
<i>root-name</i></h3>
<p><b>Section:</b> 29.11.7.4.11 <a href="https://wg21.link/fs.path.gen">[fs.path.gen]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2018-02-23 <b>Last modified:</b> 2019-07-22</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.path.gen">issues</a> in [fs.path.gen].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>path::lexically_relative</tt> constructs the resulting path with <tt>operator/=</tt>. If any of 
the filename elements from <tt>*this</tt> are themselves acceptable <i>root-name</i>s, <tt>operator/=</tt> 
will destroy any previous value, and take that <tt>root_name()</tt>. For example:
</p>
<blockquote><pre>
path("/a:/b:").lexically_relative("/a:/c:")
</pre></blockquote>
<p>
On a POSIX implementation, this would return <tt>path("../b:")</tt>, but on a Windows implementation, the 
<tt>"b:"</tt> element is interpreted as a <i>root-name</i>, and clobbers the entire result <tt>path</tt>, 
giving <tt>path("b:")</tt>. We should detect this problematic condition and fail (by returning <tt>path()</tt>).
</p>

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

<p>Set Priority to 2</p>

<p><i>[2019 Cologne Wednesday night]</i></p>

<p>Status to Ready</p>


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

<ol>
<li><p>Change 29.11.7.4.11 <a href="https://wg21.link/fs.path.gen">[fs.path.gen]</a> as indicated:</p>
<blockquote>
<pre>
path lexically_relative(const path&amp; base) const;
</pre>
<blockquote>
<p>
-3- [&hellip;]
<p/>
-4- <i>Effects:</i> If <tt>root_name() != base.root_name()</tt> is <tt>true</tt> or 
<tt>is_absolute() != base.is_absolute()</tt> is <tt>true</tt> or <tt>!has_root_directory() 
&amp;&amp; base.has_root_directory()</tt> is <tt>true</tt> <ins>or if any <i>filename</i> 
in <tt>relative_path()</tt> or <tt>base.relative_path()</tt> can be interpreted as a 
<i>root-name</i></ins>, returns <tt>path()</tt>. <ins>[<i>Note:</i> On a POSIX implementation, 
no <i>filename</i> in a <i>relative-path</i> is acceptable as a <i>root-name</i> 
&mdash; <i>end note</i>]</ins> Determines
the first mismatched element of <tt>*this</tt> and <tt>base</tt> as if by:
</p>
<blockquote><pre>
auto [a, b] = mismatch(begin(), end(), base.begin(), base.end());
</pre></blockquote>
<p>
Then,
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; if <tt>a == end()</tt> and <tt>b == base.end()</tt>, returns <tt>path(".")</tt>; 
otherwise</p></li>
<li><p>(4.2) &mdash; let <tt>n</tt> be the number of <i>filename</i> elements in <tt>[b, base.end())</tt> that 
are not dot or dot-dot minus
the number that are dot-dot. If <tt>n &lt; 0</tt>, returns <tt>path()</tt>; otherwise</p></li>
<li><p>(4.3) &mdash; returns an object of class <tt>path</tt> that is default-constructed, followed by</p>
<ol style="list-style-type: none">
<li><p>(4.3.1) &mdash; application of <tt>operator/=(path(".."))</tt> <tt>n</tt> times, and then</p></li>
<li><p>(4.3.2) &mdash; application of <tt>operator/=</tt> for each element in <tt>[a, end())</tt>.</p></li>
</ol>
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3103" href="#3103">3103</a><sup><a href="https://cplusplus.github.io/LWG/issue3103">(i)</a></sup>. Errors in taking subview of <tt>span</tt> should be ill-formed where possible</h3>
<p><b>Section:</b> 22.7.3.3 <a href="https://wg21.link/span.sub">[span.sub]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2018-04-13 <b>Last modified:</b> 2019-07-22</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently all out-of-bound/inputs errors in the functions taking an subview of <tt>span</tt> lead to undefined behavior, 
even in the situation when they could be detected at compile time. This is inconsistent with the behavior of the <tt>span</tt> 
constructors, which make similar constructs ill-formed.
<p/>
Furthermore, with the current specification of the <tt>subspan</tt> function, the following invocation:
</p>
<blockquote><pre>
span&lt;T, N&gt; s;   // N &gt; 0
s.subspan&lt;O&gt;(); // with O &gt; 0
</pre></blockquote>
<p>
is ill-formed when <tt>O &gt; N + 1</tt>, as the return of the function is <tt>span&lt;T, K&gt;</tt> with <tt>K &lt; -1</tt>.
However in case when <tt>O == N + 1</tt>, runtime sized <tt>span</tt> is returned (<tt>span&lt;T, -1&gt;</tt>) instead and 
the behavior of the function is undefined.
<p/>
Firstly, for either run time sized (<tt>N == dynamic_extent</tt>) and fixed sized (<tt>N &gt; 0</tt>) object <tt>s</tt> of 
type <tt>span&lt;T, N&gt;</tt>, the following constructs should be ill-formed, instead of having undefined behavior:
</p>
<ol>
<li><p><tt>s.first&lt;C&gt;()</tt> with <tt>C &lt; 0</tt></p></li>
<li><p><tt>s.last&lt;C&gt;()</tt> with <tt>C &lt; 0</tt></p></li>
<li><p><tt>s.subspan&lt;O, E&gt;</tt> with <tt>O &lt; 0</tt> or <tt>E &lt; 0</tt> and <tt>E != dynamic_extent</tt>.</p></li>
</ol>
<p>
This would follow <tt>span</tt> specification, that make instantiation of <tt>span&lt;T, N&gt;</tt> ill-formed for 
<tt>N &lt; 0</tt> and <tt>N != dynamic_extent</tt>.
<p/>
In addition the following constructs should be made ill-formed for fixed size span <tt>s</tt> of type 
<tt>span&lt;T, N&gt;</tt> (with <tt>N &gt; 0</tt>):
</p>
<ol>
<li><p><tt>s.first&lt;C&gt;()</tt> with <tt>C &gt; N</tt></p></li>
<li><p><tt>s.last&lt;C&gt;()</tt> with <tt>C &gt; N</tt></p></li>
<li><p><tt>s.subspan&lt;O, dynamic_extent&gt;()</tt> with <tt>O &gt; N</tt></p></li>
<li><p><tt>s.subspan&lt;O, C&gt;()</tt> with <tt>O + C &gt; N</tt></p></li>
</ol>
<p>
This will match the <tt>span</tt> constructor that made construction of fixed size <tt>span&lt;T, N&gt;</tt> from fixed 
size <tt>span</tt> of different size ill-formed.
</p>

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


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

<p>Tomasz to provide updated wording.</p>

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

<blockquote>
<ol>
<li>
<p>Edit 22.7.3.3 <a href="https://wg21.link/span.sub">[span.sub]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;ptrdiff_t Count&gt; constexpr span&lt;element_type, Count&gt; first() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Remarks:</i> If <tt>Count &lt; 0 || (Extent != dynamic_extent &amp;&amp; Count &gt; Extent)</tt>, 
the program is ill-formed.</ins>
<p/>
-1- <i>Requires:</i> <tt><del>0 &lt;= Count &amp;&amp;</del> Count &lt;= size()</tt>.
<p/>
-2- <i>Effects:</i> Equivalent to: <tt>return {data(), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;ptrdiff_t Count&gt; constexpr span&lt;element_type, Count&gt; last() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Remarks:</i> If <tt>Count &lt; 0 || (Extent != dynamic_extent &amp;&amp; Count &gt; Extent)</tt>, 
the program is ill-formed.</ins>
<p/>
-3- <i>Requires:</i> <tt><del>0 &lt;= Count &amp;&amp;</del> Count &lt;= size()</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to: <tt>return {data() + (size() - Count), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;ptrdiff_t Offset, ptrdiff_t Count = dynamic_extent&gt;
  constexpr span&lt;element_type, <i>see below</i>&gt; subspan() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Remarks:</i> The program is ill-formed if:</ins>
<ul>
<li><p><ins><tt>Offset &lt; 0 || (Count &lt; 0 &amp;&amp; Count != dynamic_extent)</tt>, or</ins></p></li>
<li><p><ins><tt>Extend != dynamic_extent &amp;&amp; (Offset &gt; Extent || (Count != dynamic_extent &amp;&amp; 
Offset + Count &gt; Extent))</tt>.</ins></p></li>
</ul>
<p/>
-5- <i>Requires:</i> <tt><del>(0 &lt;= Offset &amp;&amp;</del> Offset &lt;= size()<del>)</del> &amp;&amp; 
(Count == dynamic_extent || <del>Count &gt;= 0 &amp;&amp;</del> Offset + Count &lt;= size())</tt>.
<p/>
-6- <i>Effects:</i> Equivalent to: <tt>return span&lt;ElementType, <i>see below</i>&gt;(
data() + Offset, Count != dynamic_extent ? Count : size() - Offset);</tt>
<p/>
-7- <i>Remarks:</i> The second template argument of the returned <tt>span</tt> type is:
</p>
<blockquote><pre>
Count != dynamic_extent ? Count
                        : (Extent != dynamic_extent ? Extent - Offset
                                                    : dynamic_extent)
</pre></blockquote>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
</blockquote>

<p><i>[2018-11-09; Tomasz provides updated wording]</i></p>

<p>
I have decided to replace all <i>Requires:</i> elements in the section 22.7.3.3 <a href="https://wg21.link/span.sub">[span.sub]</a> to preserve consistency.
</p>

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

<blockquote>
<ol>
<li>
<p>Edit 22.7.3.3 <a href="https://wg21.link/span.sub">[span.sub]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;ptrdiff_t Count&gt; constexpr span&lt;element_type, Count&gt; first() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Count &gt;= 0 &amp;&amp; (Extent == dynamic_extent || Count &lt;= Extent)</tt>.</ins>
<p/>
-1- <i><del>Requires</del><ins>Expects</ins>:</i> <tt><del>0 &lt;= Count &amp;&amp;</del> Count &lt;= size()</tt>.
<p/>
-2- <i>Effects:</i> Equivalent to: <tt>return {data(), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;ptrdiff_t Count&gt; constexpr span&lt;element_type, Count&gt; last() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Count &gt;= 0 &amp;&amp; (Extent == dynamic_extent || Count &lt;= Extent)</tt>.</ins>
<p/>
-3- <i><del>Requires</del><ins>Expects</ins>:</i> <tt><del>0 &lt;= Count &amp;&amp;</del> Count &lt;= size()</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to: <tt>return {data() + (size() - Count), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;ptrdiff_t Offset, ptrdiff_t Count = dynamic_extent&gt;
  constexpr span&lt;element_type, <i>see below</i>&gt; subspan() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Offset &gt;= 0 &amp;&amp; (Count &gt;= 0 || Count == dynamic_extent) &amp;&amp;
(Extent == dynamic_extent || (Offset &lt;= Extent &amp;&amp; (Count == dynamic_extent || Offset + Count &lt;= Extent)))</tt>.</ins>
<p/>
-5- <i><del>Requires</del><ins>Expects</ins>:</i> <tt><del>(0 &lt;= Offset &amp;&amp;</del> Offset &lt;= size()<del>)</del> &amp;&amp; 
(Count == dynamic_extent || <del>Count &gt;= 0 &amp;&amp;</del> Offset + Count &lt;= size())</tt>.
<p/>
-6- <i>Effects:</i> Equivalent to: <tt>return span&lt;ElementType, <i>see below</i>&gt;(
data() + Offset, Count != dynamic_extent ? Count : size() - Offset);</tt>
<p/>
-7- <i>Remarks:</i> The second template argument of the returned <tt>span</tt> type is:
</p>
<blockquote><pre>
Count != dynamic_extent ? Count
                        : (Extent != dynamic_extent ? Extent - Offset
                                                    : dynamic_extent)
</pre></blockquote>
</blockquote>
<pre>
constexpr span&lt;element_type, dynamic_extent&gt; first(index_type count) const;
</pre>
<blockquote>
<p>
-8- <i><del>Requires</del><ins>Expects</ins>:</i> <tt>0 &lt;= count &amp;&amp; count &lt;= size()</tt>.
<p/>
-9- <i>Effects:</i> Equivalent to: <tt>return {data(), count};</tt>
</p>

</blockquote>
<pre>
constexpr span&lt;element_type, dynamic_extent&gt; last(index_type count) const;
</pre>
<blockquote>
<p>
-10- <i><del>Requires</del><ins>Expects</ins>:</i> <tt>0 &lt;= count &amp;&amp; count &lt;= size()</tt>.
<p/>
-11- <i>Effects:</i> Equivalent to: <tt>return {data() + (size() - count), count};</tt>
</p>
</blockquote>
<pre>
constexpr span&lt;element_type, dynamic_extent&gt; subspan(
  index_type offset, index_type count = dynamic_extent) const;
</pre>
<blockquote>
<p>
-12- <i><del>Requires</del><ins>Expects</ins>:</i> <tt>(0 &lt;= offset &amp;&amp; offset &lt;= size())
&amp;&amp; (count == dynamic_extent || count &gt;= 0 &amp;&amp; offset + count &lt;= size())</tt>
<p/>
-13- <i>Effects:</i> Equivalent to: <tt>return {data() + offset, count == dynamic_extent ? size() - offset : count};</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>
</blockquote>

<p><i>[2019-06-23; Tomasz comments and provides updated wording]</i></p>

<p>
The current proposed resolution no longer applies to the newest revision of the standard 
(<a href="http://wg21.link/n4820">N4820</a>), due changes introduced in 
<a href="http://wg21.link/p1227">P1227</a> (making <tt>size()</tt> and template parameters 
of <tt>span</tt> unsigned).
</p>

<p><i>[2019 Cologne Wednesday night]</i></p>

<p>Status to Ready</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">
[<i>Drafting note:</i> This wording relies on observation, that the condition in form 
<code>Extent == dynamic_extent || Count &lt;= Extent</code>, can be simplified into 
<code>Count &lt;= Extent</code>, because <code>dynamic_extent</code> is equal to 
<code>numeric_limits&lt;size_t&gt;::max()</code>, thus <code>size() &lt;= Extent</code> 
is always true, and <code>Extent == dynamic_extent</code> implies that <code>Count &lt;= Extent</code>.
<p/>
Furthermore we check that <code>Count != dynamic_extent || Count &lt;= Extent - Offset</code>, 
as the <code>Offset + Count &lt;= Extent</code> may overflow (defined for unsigned integers) and 
produce false positive result. This change is also applied to <i>Expects</i> clause. ]
</blockquote>

<blockquote>
<ol>
<li>
<p>Edit 22.7.3.3 <a href="https://wg21.link/span.sub">[span.sub]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;size_t Count&gt; constexpr span&lt;element_type, Count&gt; first() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Count &lt;= Extent</tt> is <tt>true</tt>.</ins>
<p/>
-1- <i>Expects:</i> <tt>Count &lt;= size()</tt> is <tt>true</tt>.
<p/>
-2- <i>Effects:</i> Equivalent to: <tt>return {data(), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;size_t Count&gt; constexpr span&lt;element_type, Count&gt; last() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Count &lt;= Extent</tt> is <tt>true</tt>.</ins>
<p/>
-3- <i>Expects:</i> <tt>Count &lt;= size()</tt> is <tt>true</tt>.
<p/>
-4- <i>Effects:</i> Equivalent to: <tt>return {data() + (size() - Count), Count};</tt>
</p>
</blockquote>
<pre>
template&lt;size_t Offset, size_t Count = dynamic_extent&gt;
  constexpr span&lt;element_type, <i>see below</i>&gt; subspan() const;
</pre>
<blockquote>
<p>
<ins>-?- <i>Mandates:</i> <tt>Offset &lt;= Extent &amp;&amp; (Count == dynamic_extent || 
Count &lt;= Extent - Offset)</tt> is <tt>true</tt>.</ins>
<p/>
-5- <i>Expects:</i> <tt>Offset &lt;= size() &amp;&amp; (Count == dynamic_extent || <del>Offset + 
Count &lt;= size()</del><ins>Count &lt;= size() - Offset</ins>)</tt> is <tt>true</tt>.
<p/>
-6- <i>Effects:</i> Equivalent to: <tt>return span&lt;ElementType, <i>see below</i>&gt;(data() 
+ Offset, Count != dynamic_extent ? Count : size() - Offset);</tt>
<p/>
-7- <i>Remarks:</i> The second template argument of the returned <tt>span</tt> type is:
</p>
<blockquote><pre>
Count != dynamic_extent ? Count
                        : (Extent != dynamic_extent ? Extent - Offset
                                                    : dynamic_extent)
</pre></blockquote>
</blockquote>
[&hellip;]
<pre>
constexpr span&lt;element_type, dynamic_extent&gt; subspan(
  index_type offset, index_type count = dynamic_extent) const;
</pre>
<blockquote>
<p>
-12- <i>Expects:</i> <tt>offset &lt;= size() &amp;&amp; (count == dynamic_extent || <del>offset + 
count &lt;= size()</del><ins>count &lt;= size() - offset</ins>)</tt> is <tt>true</tt>.
<p/>
-13- <i>Effects:</i> Equivalent to: <tt>return {data() + offset, count == dynamic_extent ? size() - offset : count};</tt>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>





<hr>
<h3><a name="3149" href="#3149">3149</a><sup><a href="https://cplusplus.github.io/LWG/issue3149">(i)</a></sup>. <tt>DefaultConstructible</tt> should require default initialization</h3>
<p><b>Section:</b> 18.4.12 <a href="https://wg21.link/concept.defaultconstructible">[concept.defaultconstructible]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-08-09 <b>Last modified:</b> 2019-07-22</p>
<p><b>Priority: </b>2
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>DefaultConstructible&lt;T&gt;</tt> is equivalent to
<tt>Constructible&lt;T&gt;</tt> (18.4.11 <a href="https://wg21.link/concept.constructible">[concept.constructible]</a>), which
is equivalent to <tt>is_constructible_v&lt;T&gt;</tt>
(20.15.4.3 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a>). Per 20.15.4.3 <a href="https://wg21.link/meta.unary.prop">[meta.unary.prop]</a>
<a href="https://wg21.link/meta.unary.prop#8">paragraph 8</a>:
<blockquote>
<p>The predicate condition for a template specialization
<tt>is_­constructible&lt;T, Args...&gt;</tt> shall be satisfied if and only if
the following variable definition would be well-formed for some invented
variable <tt>t</tt>:</p>
<blockquote>
<pre>
T t(declval&lt;Args&gt;()...);
</pre>
</blockquote>
</blockquote>
<tt>DefaultConstructible&lt;T&gt;</tt> requires that objects of type <tt>T</tt>
can be
<a href="https://wg21.link/dcl.init#8"><i>value-initialized</i></a>,
rather than
<a href="https://wg21.link/dcl.init#7"><i>default-initialized</i></a>
as intended.
</p>
<p>
The library needs a constraint that requires object types to be
default-initializable: the "rangified" versions of the algorithms in
20.10.11.3 <a href="https://wg21.link/uninitialized.construct.default">[uninitialized.construct.default]</a> proposed in
<a href="https://wg21.link/p0896">P0896 "The One Ranges Proposal"</a>, for
example. Users will also want a mechanism to provide such a constraint, and
they're likely to choose <tt>DefaultConstructible</tt> despite its subtle
unsuitability.
</p>
<p>
There are two alternative solutions: (1) change <tt>DefaultConstructible</tt>
to require <i>default-initialization</i>, (2) change
<tt>is_default_constructible_v</tt> to require default-initializaton and specify
the concept in terms of the trait. (2) is probably too breaking a change to be
feasible.
</p>

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

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li><p>Modify 18.4.12 <a href="https://wg21.link/concept.defaultconstructible">[concept.defaultconstructible]</a> as follows:</p>

<blockquote>
<pre>
template&lt;class T&gt;
  concept DefaultConstructible = Constructible&lt;T&gt; <ins>&amp;&amp; see below</ins>;
</pre>
<p>
<ins>-?- Type <tt>T</tt> models <tt>DefaultConstructible</tt> only if the variable
definition</ins>
<blockquote>
<pre>
<ins>T t;</ins>
</pre>
</blockquote>
<ins>is well-formed for some invented variable <tt>t</tt>. Access checking is
performed as if in a context unrelated to <tt>T</tt>. Only the validity of the
immediate context of the variable initialization is considered.</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2018-08-23 Tim provides updated P/R based on Batavia discussion]</i></p>


<p><i>[2018-10-28 Casey expands the problem statement and the P/R]</i></p>

<p>
During Batavia review of <a href="https://wg21.link/p0896r3">P0896R3</a>, Tim
Song noted that <tt>{}</tt> is not necessarily a valid initializer for a
<tt>DefaultConstructible</tt> type. In this sample program
(see <a href="https://godbolt.org/z/I64p_E">Compiler Explorer</a>):
<blockquote>
<pre>
struct S0 { explicit S0() = default; };
struct S1 { S0 x; }; // Note: aggregate
S1 x;   // Ok
S1 y{}; // ill-formed; copy-list-initializes x from {}
</pre>
</blockquote>
<tt>S1</tt> can be default-initialized, but not list-initialized from an empty
<i>braced-init-list</i>. The consensus among those present was that
<tt>DefaultConstructible</tt> should prohibit this class of pathological types
by requiring that initialization form to be valid.
</p>

<p><i>[2019 Cologne Wednesday night]</i></p>

<p>Status to Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="https://wg21.link/n4762">N4762</a>.</p>
<ol>
<li><p>Modify 18.4.12 <a href="https://wg21.link/concept.defaultconstructible">[concept.defaultconstructible]</a> as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;
  inline constexpr bool <i>is-default-initializable</i> = <i>see below</i>; // <i>exposition only</i></ins>

template&lt;class T&gt;
  concept DefaultConstructible = Constructible&lt;T&gt; <ins>&amp;&amp; requires { T{}; } &amp;&amp; <i>is-default-initializable</i>&lt;T&gt;</ins>;
</pre>
<p>
<ins>-?- For a type <tt>T</tt>, <tt><i>is-default-initializable</i>&lt;T&gt;</tt> is <tt>true</tt>
if and only if the variable definition</ins>
<blockquote>
<pre>
<ins>T t;</ins>
</pre>
</blockquote>
<ins>is well-formed for some invented variable <tt>t</tt>; otherwise it is <tt>false</tt>. Access checking is
performed as if in a context unrelated to <tt>T</tt>. Only the validity of the
immediate context of the variable initialization is considered.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3190" href="#3190">3190</a><sup><a href="https://cplusplus.github.io/LWG/issue3190">(i)</a></sup>. <tt>std::allocator::allocate</tt> sometimes returns too little storage</h3>
<p><b>Section:</b> 20.10.10.1 <a href="https://wg21.link/allocator.members">[allocator.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-02-20 <b>Last modified:</b> 2019-07-22</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#allocator.members">active issues</a> in [allocator.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#allocator.members">issues</a> in [allocator.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.10.10.1 <a href="https://wg21.link/allocator.members">[allocator.members]</a>/2 says:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
<p>
-2- <i>Returns:</i> A pointer to the initial element of an array of storage of size <tt>n * sizeof(T)</tt>, aligned 
appropriately for objects of type <tt>T</tt>.
</p>
</blockquote>
<p>
As in LWG <a href="lwg-defects.html#3038">3038</a>, we should not return too little storage for n objects of size <tt>sizeof(T)</tt>, e.g. 
when <tt>n</tt> is <tt>SIZE_MAX / 2</tt> and <tt>T</tt> is <tt>short</tt>.
</p>

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


<p><i>[2019 Cologne Wednesday night]</i></p>

<p>Status to Ready; will open additional issue to reconcile this and <a href="lwg-defects.html#3038">3038</a></p>


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

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

<blockquote>
<pre>
[[nodiscard]] T* allocate(size_t n);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Throws:</i> <ins><tt>bad_array_new_length</tt> if <tt>SIZE_MAX / sizeof(T) &lt; n</tt>, or</ins> <tt>bad_alloc</tt> 
if the storage cannot be obtained.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3218" href="#3218">3218</a><sup><a href="https://cplusplus.github.io/LWG/issue3218">(i)</a></sup>. Modifier for <tt>%d</tt> parse flag does not match POSIX and <tt>format</tt> specification</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-13 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently, the '<code>%d</code>' parse flags accepts the '<code>E</code>' modifier to parse the
locale's alternative representation, see Table 88 &mdash;
<a href="http://eel.is/c++draft/time.parse#11.sentence-26">
"Meaning of <code>parse</code> flags"</a>:
</p>
<blockquote><p>
The modified command <code>%Ed</code> interprets the locale's
alternative representation of the day of the month.
</p></blockquote>
<p>
This is inconsistent with the
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html">POSIX
<code>strftime</code> specification</a> and the <tt>format</tt> functions, that uses '<code>O</code>'
to output alternate locale representation. Per Table 87 &mdash;
<a href="http://eel.is/c++draft/time.format#17.sentence-28">"Meaning of <code>format</code>
conversion specifiers"</a>:
</p>
<blockquote><p>
The modified command <code>%Od</code> produces the locale's alternative representation.
</p></blockquote>

<p><i>[2019-06-24; Howard comments]</i></p>

<p>
This was simply a type-o in my documentation that infected the proposal and subsequently the C++ working draft.
<p/>
None of <tt>std::time_put</tt>, C's <tt>strftime</tt>, or POSIX's <tt>strftime</tt> support
<tt>%Ed</tt> but all support <tt>%Od</tt>. Furthermore the existing example implementation
supports <tt>%Od</tt> but not <tt>%Ed</tt>. And all the existing example implementation
does is forward to <tt>std::time_put</tt>.
</p>

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

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


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

<ol>
<li><p>Modify 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a>, Table 88 &mdash; "Meaning of <code>parse</code> flags",
as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 88 &mdash; Meaning of <code>parse</code> flags</caption>
<tr style="text-align:center">
<th>Flag</th>
<th>Parsed value</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td><tt>%d</tt></td>
<td>The day of the month as a decimal number. The modified command <tt>%<i>N</i>d</tt>
specifies the maximum number of characters to read. If <tt><i>N</i></tt> is not specified,
the default is 2. Leading zeroes are permitted but not required. The modified command
<tt>%<del>E</del><ins>O</ins>d</tt> interprets the locale's alternative representation
of the day of the month.</td>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

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




<hr>
<h3><a name="3221" href="#3221">3221</a><sup><a href="https://cplusplus.github.io/LWG/issue3221">(i)</a></sup>. Result of <tt>year_month</tt> arithmetic with <tt>months</tt> is ambiguous</h3>
<p><b>Section:</b> 27.8.13.3 <a href="https://wg21.link/time.cal.ym.nonmembers">[time.cal.ym.nonmembers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-16 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification of the addition of <code>year_month</code> and
<code>months</code> does not define a unique result value.
<p/>
To illustrate, both  <code>year(2019)/month(1)</code> and <code>year(2018)/month(13)</code>
are valid results of <code>year(2018)/month(12) + months(1)</code> addition,
according to the spec in 27.8.13.3 <a href="https://wg21.link/time.cal.ym.nonmembers">[time.cal.ym.nonmembers]</a>.
</p>

<p><i>[2019-06-24; LWG discussion]</i></p>

<p>
During discussions on the LWG reflector there was a preference to add "is <tt>true</tt>" at the
end of the modified <i>Returns:</i> element. This additional edit has been applied to Tomasz'
original wording below.
</p>

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

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


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

<ol>
<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>
-3- <i>Returns:</i> A <tt>year_month</tt> value <tt>z</tt> such that <tt><ins>z.ok() &amp;&amp;</ins>
z - ym == dm</tt> <ins>is <tt>true</tt></ins>.
<p/>
<i>Complexity:</i> <tt>&#x1d4aa;(1)</tt> with respect to the value of <tt>dm</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3222" href="#3222">3222</a><sup><a href="https://cplusplus.github.io/LWG/issue3222">(i)</a></sup>. P0574R1 introduced preconditions on non-existent parameters</h3>
<p><b>Section:</b> 25.9.8 <a href="https://wg21.link/inclusive.scan">[inclusive.scan]</a>, 25.9.10 <a href="https://wg21.link/transform.inclusive.scan">[transform.inclusive.scan]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-06-18 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
after applying <a href="http://wg21.link/p0574r1">P0574R1</a> to the working draft,
25.9.10 <a href="https://wg21.link/transform.inclusive.scan">[transform.inclusive.scan]</a> bullet 1.1 says "If <tt>init</tt> is provided, [&hellip;];
otherwise, <tt>ForwardIterator1</tt>'s value type shall be [&hellip;]."
25.9.10 <a href="https://wg21.link/transform.inclusive.scan">[transform.inclusive.scan]</a> bullet 1.2 says "If <tt>init</tt> is provided, [&hellip;];
otherwise, [&hellip;] shall be convertible to <tt>ForwardIterator1</tt>'s value type."
<p/>
For the first overload <tt>init</tt> is not provided, but there is no <tt>ForwardIterator1</tt>, so
these requirements cannot be met. The requirements for the first overload need to be stated in terms
of <tt>InputIterator</tt>'s value type, not <tt>ForwardIterator1</tt>'s value type.
<p/>
The same problem exists in 25.9.8 <a href="https://wg21.link/inclusive.scan">[inclusive.scan]</a>. 25.9.11 <a href="https://wg21.link/adjacent.difference">[adjacent.difference]</a> solves
this problem by saying "Let <tt>T</tt> be the value type of <tt>decltype(first)</tt>".
</p>

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

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


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

<ol>
<li><p>Modify 25.9.8 <a href="https://wg21.link/inclusive.scan">[inclusive.scan]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator, class OutputIterator, class BinaryOperation&gt;
  OutputIterator inclusive_scan(InputIterator first, InputIterator last,
                                OutputIterator result, BinaryOperation binary_op);
template&lt;class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2,
         class BinaryOperation&gt;
  ForwardIterator2 inclusive_scan(ExecutionPolicy&amp;&amp; exec,
                                  ForwardIterator1 first, ForwardIterator1 last,
                                  ForwardIterator2 result, BinaryOperation binary_op);
template&lt;class InputIterator, class OutputIterator, class BinaryOperation, class T&gt;
  OutputIterator inclusive_scan(InputIterator first, InputIterator last,
                                OutputIterator result, BinaryOperation binary_op, T init);
template&lt;class ExecutionPolicy,
         class ForwardIterator1, class ForwardIterator2, class BinaryOperation, class T&gt;
  ForwardIterator2 inclusive_scan(ExecutionPolicy&amp;&amp; exec,
                                  ForwardIterator1 first, ForwardIterator1 last,
                                  ForwardIterator2 result, BinaryOperation binary_op, T init);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>U</tt> be the value type of <tt>decltype(first)</tt>.</ins>
<p/>
-3- <i>Requires:</i>
</p>
<ol style="list-style-type:none">
<li><p>(3.1) &mdash; If <tt>init</tt> is provided, <tt>T</tt> shall be <i>Cpp17MoveConstructible</i> (Table 26); otherwise, <del><tt>ForwardIterator1</tt>'s value type</del><ins><tt>U</tt></ins> shall be
<i>Cpp17MoveConstructible</i>.</p></li>
<li><p>(3.2) &mdash; If <tt>init</tt> is provided, all of <tt>binary_op(init, init)</tt>, <tt>binary_op(init,
*first)</tt>, and <tt>binary_op(*first, *first)</tt> shall be convertible to <tt>T</tt>; otherwise,
<tt>binary_op(*first, *first)</tt> shall be convertible to <del><tt>ForwardIterator1</tt>'s value
type</del><ins><tt>U</tt></ins>.</p></li>
<li><p>(3.3) &mdash; <tt>binary_op</tt> shall neither invalidate iterators or subranges, nor modify elements
in the ranges <tt>[first, last]</tt> or <tt>[result, result + (last - first)]</tt>.</p></li>
</ol>
</blockquote>
</blockquote>
</li>

<li><p>Modify 25.9.10 <a href="https://wg21.link/transform.inclusive.scan">[transform.inclusive.scan]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator, class OutputIterator,
         class BinaryOperation, class UnaryOperation&gt;
  OutputIterator transform_inclusive_scan(InputIterator first, InputIterator last,
                                          OutputIterator result,
                                          BinaryOperation binary_op, UnaryOperation unary_op);
template&lt;class ExecutionPolicy,
         class ForwardIterator1, class ForwardIterator2,
         class BinaryOperation, class UnaryOperation&gt;
  ForwardIterator2 transform_inclusive_scan(ExecutionPolicy&amp;&amp; exec,
                                            ForwardIterator1 first, ForwardIterator1 last,
                                            ForwardIterator2 result,
                                            BinaryOperation binary_op, UnaryOperation unary_op);
template&lt;class InputIterator, class OutputIterator,
         class BinaryOperation, class UnaryOperation, class T&gt;
  OutputIterator transform_inclusive_scan(InputIterator first, InputIterator last,
                                          OutputIterator result,
                                          BinaryOperation binary_op, UnaryOperation unary_op,
                                          T init);
template&lt;class ExecutionPolicy,
         class ForwardIterator1, class ForwardIterator2,
         class BinaryOperation, class UnaryOperation, class T&gt;
  ForwardIterator2 transform_inclusive_scan(ExecutionPolicy&amp;&amp; exec,
                                            ForwardIterator1 first, ForwardIterator1 last,
                                            ForwardIterator2 result,
                                            BinaryOperation binary_op, UnaryOperation unary_op,
                                            T init);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>U</tt> be the value type of <tt>decltype(first)</tt>.</ins>
<p/>
-1- <i>Requires:</i>
</p>
<ol style="list-style-type:none">
<li><p>(1.1) &mdash; If <tt>init</tt> is provided, <tt>T</tt> shall be <i>Cpp17MoveConstructible</i> (Table 26); otherwise, <del><tt>ForwardIterator1</tt>'s value type</del><ins><tt>U</tt></ins> shall be
<i>Cpp17MoveConstructible</i>.</p></li>
<li><p>(1.2) &mdash; If <tt>init</tt> is provided, all of</p>
<ol style="list-style-type:none">
<li><p>(1.2.1) &mdash; <tt>binary_op(init, init)</tt>,</p></li>
<li><p>(1.2.2) &mdash; <tt>binary_op(init, unary_op(*first))</tt>, and</p></li>
<li><p>(1.2.3) &mdash; <tt>binary_op(unary_op(*first), unary_op(*first))</tt></p></li>
</ol>
<p>shall be convertible to <tt>T</tt>; otherwise, <tt>binary_op(unary_op(*first), unary_op(*first))</tt>
shall be convertible to <del><tt>ForwardIterator1</tt>'s value type</del><ins><tt>U</tt></ins>.</p></li>
<li><p>(1.3) &mdash; Neither <tt>unary_op</tt> nor <tt>binary_op</tt> shall invalidate iterators or subranges,
nor modify elements in the ranges <tt>[first, last]</tt> or <tt>[result, result + (last - first)]</tt>.</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3224" href="#3224">3224</a><sup><a href="https://cplusplus.github.io/LWG/issue3224">(i)</a></sup>. <tt>zoned_time</tt> constructor from <tt>TimeZonePtr</tt> does not specify initialization of
<tt>tp_</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-20 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.zone.zonedtime.ctor">active issues</a> in [time.zone.zonedtime.ctor].</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <code>zoned_time(TimeZonePtr z)</code> does not specify how the <code>tp_</code>
sub-element is initialized. It should be consistent with <code>zoned_time(string_view)</code>
that default initializes <code>tp_</code>.
</p>

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

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


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

<ol>
<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>
explicit zoned_time(TimeZonePtr z);
</pre>
<blockquote>
<p>
-5- <i>Requires:</i> <tt>z</tt> refers to a time zone.
<p/>
-6- <i>Effects:</i> Constructs a <tt>zoned_time</tt> by initializing <tt>zone_</tt> with <tt>std::move(z)</tt>
<ins>and default constructing <tt>tp_</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3225" href="#3225">3225</a><sup><a href="https://cplusplus.github.io/LWG/issue3225">(i)</a></sup>. <tt>zoned_time</tt> converting constructor shall not be <tt>noexcept</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-20 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.zone.zonedtime.ctor">active issues</a> in [time.zone.zonedtime.ctor].</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <code>zoned_time</code> constructor from <code>zoned_time&lt;Duration2,
TimeZonePtr&gt;</code> (preserving same time zone, different precision of
representation) is currently marked <tt>noexcept</tt>. Given that the <i>exposition-only</i>
member <tt>tp_</tt> of type <tt>sys_time&lt;duration&gt;</tt> has essentially type
<tt>time_point&lt;system_clock, Duration&gt;</tt>, this is incompatible with the
invoked <code>time_point</code> constructor, which is not marked as <tt>noexcept</tt>.
</p>

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

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


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/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>
template&lt;class Duration2&gt;
  zoned_time(const zoned_time&lt;Duration2, TimeZonePtr&gt;&amp; zt) <del>noexcept</del>;
</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>
template&lt;class Duration2&gt;
  zoned_time(const zoned_time&lt;Duration2, TimeZonePtr&gt;&amp; y) <del>noexcept</del>;
</pre>
<blockquote>
<p>
-9- <i>Requires:</i> Does not participate in overload resolution unless <tt>sys_time&lt;Duration2&gt;</tt>
is implicitly convertible to <tt>sys_time&lt;Duration&gt;</tt>.
<p/>
-10- <i>Effects:</i> Constructs a <tt>zoned_time</tt> by initializing <tt>zone_</tt> with
<tt>y.zone_</tt> and <tt>tp_</tt> with <tt>y.tp_</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3230" href="#3230">3230</a><sup><a href="https://cplusplus.github.io/LWG/issue3230">(i)</a></sup>. Format specifier <tt>%y/%Y</tt> is missing locale alternative versions</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-29 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The year format specifier <tt>('y', 'Y')</tt> are missing the locale alternative
version <tt>('%EY', '%Ey' and '%Oy')</tt>. That makes it inconsistent with the
<a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strftime.html">POSIX
<code>strftime</code> specification</a>:
</p>
<ol style="list-style-type:none">
<li><p><tt>%Ey</tt>&emsp;Replaced by the offset from <tt>%EC</tt> (year only) in the locale's
alternative representation.</p></li>
<li><p><tt>%EY</tt>&emsp;Replaced by the full alternative year representation.</p></li>
<li><p><tt>%Oy</tt>&emsp;Replaced by the year (offset from <tt>%C</tt>) using the locale's
alternative numeric symbols.</p></li>
</ol>
<p>
and <code>parse</code> specifiers 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> that accepts these modified command.
</p>

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

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


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

<blockquote class="note">
<p>
[<i>Drafting note:</i> For the <tt>'%Oy'</tt> specifier we preserve consistency with the current
specification for <tt>'%Od'</tt> and <tt>'%Oe'</tt> from Table 87 "Meaning of <code>format</code>
conversion specifier"  [tab:time.format.spec]:
</p>
<ol style="list-style-type:none">
<li><p><tt>%d</tt>&emsp;[&hellip;] The modified command <code>%Od</code> produces the locale's
alternative representation.</p></li>
<li><p><tt>%e</tt>&emsp;[&hellip;] The modified command <code>%Oe</code> produces the locale's
alternative representation.</p></li>
</ol>
<p>
as their corresponding POSIX specification is matching one for <tt>'%Oy'</tt>:
</p>
<ol style="list-style-type:none">
<li><p><tt>%Od</tt>&emsp;Replaced by the day of the month, using the locale's alternative
numeric symbols, filled as needed with leading zeros if there is any
alternative symbol for zero; otherwise, with leading <tt>&lt;space&gt;</tt> characters.</p></li>
<li><p><tt>%Oe</tt>&emsp;Replaced by the day of the month, using the locale's alternative
numeric symbols, filled as needed with leading <tt>&lt;space&gt;</tt> characters.</p></li>
</ol>
<p>
]
</p>
</blockquote>

<ol>
<li><p>Modify "Table 87 &mdash; Meaning of <code>format</code> conversion specifiers"
 [tab:time.format.spec] as indicated:</p>

<blockquote>

<table border="1">
<caption>Table 87 &mdash; Meaning of <tt>format</tt> 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>%y</tt></td>
<td>The last two decimal digits of the year. If the result is a single digit it is prefixed by <tt>0</tt>.
<ins>The modified command <code>%Oy</code> produces the locale's
alternative representation. The modified command <code>%Ey</code> produces the locale's alternative
representation of offset from <code>%EC</code> (year only).</ins></td>
</tr>
<tr>
<td><tt>%Y</tt></td>
<td>The year as a decimal number. If the result is less than four digits it is left-padded
with <tt>0</tt> to four digits. <ins>The modified command <code>%EY</code> produces the locale's
alternative full year representation.</ins></td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>

</blockquote>

</li>
</ol>




<hr>
<h3><a name="3231" href="#3231">3231</a><sup><a href="https://cplusplus.github.io/LWG/issue3231">(i)</a></sup>. <tt>year_month_day_last::day</tt> specification does not cover <tt>!ok()</tt> values</h3>
<p><b>Section:</b> 27.8.15.2 <a href="https://wg21.link/time.cal.ymdlast.members">[time.cal.ymdlast.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-29 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification of the <code>year_month_day_last::day</code>
function does not cover the behaviour in the situation when <code>year_month_day_last</code>
value is not <code>ok()</code>. To illustrate the sentence from
27.8.15.2 <a href="https://wg21.link/time.cal.ymdlast.members">[time.cal.ymdlast.members]</a> p13:
</p>
<blockquote><p>
A <code>day</code> representing the last day of the (<code>year</code>, <code>month</code>)
pair represented by <code>*this</code>.
</p></blockquote>
<p>
is unclear in the situation when <code>month</code> member has
<code>!ok</code> value, e.g. what is last day of 14th month of 2019.
<p/>
The proposed resolution makes the value of <code>ymdl.day()</code> (and by
consequence conversion to <code>sys_days</code>/<code>local_days</code>)
unspecified if <code>ymdl.ok()  </code> is <code>false</code>. This make is
consistent with rest of the library, that produces unspecified values in
similiar situation, e.g.: 27.8.14.2 <a href="https://wg21.link/time.cal.ymd.members">[time.cal.ymd.members]</a> p18,
27.8.16.2 <a href="https://wg21.link/time.cal.ymwd.members">[time.cal.ymwd.members]</a> p19,
27.8.17.2 <a href="https://wg21.link/time.cal.ymwdlast.members">[time.cal.ymwdlast.members]</a> p14.
</p>

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

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


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

<ol>
<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 chrono::day day() const noexcept;
</pre>
<blockquote>
<p>
-13- <i>Returns:</i> <ins>If <tt>ok()</tt> is <tt>true</tt>, returns a</ins><del>A</del> <tt>day</tt>
representing the last day of the (<tt>year, month</tt>) pair represented by <tt>*this</tt>.
<ins>Otherwise the returned value is unspecified.</ins>
<p/>
-14- [<i>Note:</i> This value may be computed on demand. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>

</li>
</ol>




<hr>
<h3><a name="3232" href="#3232">3232</a><sup><a href="https://cplusplus.github.io/LWG/issue3232">(i)</a></sup>. Inconsistency in <tt>zoned_time</tt> deduction guides</h3>
<p><b>Section:</b> 27.11.7.1 <a href="https://wg21.link/time.zone.zonedtime.overview">[time.zone.zonedtime.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-06-30 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.zone.zonedtime.overview">active issues</a> in [time.zone.zonedtime.overview].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.zone.zonedtime.overview">issues</a> in [time.zone.zonedtime.overview].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently, the <code>time_zone</code> is always storing the time with
the precision not coarser that <code>seconds</code>, as consequence any
instance with the duration with coarser precision with <code>seconds</code>,
is de-facto equivalent to one instantiated to the duration of seconds.
This is caused by the fact, that time zone offset can be defined up to
seconds precision. To illustrate both of following specialization has
the same behavior (keep <code>seconds</code>):
</p>
<blockquote><pre>
zoned_time&lt;minutes&gt; zt(current_zone(), floor&lt;minutes&gt;(system_clock::now());
zoned_time&lt;hours&gt;   zt(current_zone(), floor&lt;hours&gt;(system_clock::now());
zoned_time&lt;seconds&gt; zt(current_zone(), floor&lt;seconds&gt;(system_clock::now());
</pre></blockquote>
<p>
To avoid unnecessary code bloat caused by above, most deduction guides
are instantiating <code>zoned_time</code> with at least <code>seconds</code>
precision (i.e. <code>zoned_time&lt;seconds&gt;</code> will be deduced
for all of above):
</p>
<blockquote><pre>
template&lt;class TimeZonePtr, class Duration>
  zoned_time(TimeZonePtr, zoned_time&lt;Duration>, choose = choose::earliest)
    -&gt; zoned_time&lt;common_type_t&lt;Duration, seconds&gt;, TimeZonePtr&gt;;
</pre></blockquote>
<p>
However there is single exception:
</p>
<blockquote><pre>
template&lt;class Duration, class TimeZonePtr, class TimeZonePtr2&gt;
  zoned_time(TimeZonePtr, zoned_time&lt;Duration, TimeZonePtr2&gt;, choose = choose::earliest)
     -&gt; zoned_time&lt;Duration, TimeZonePtr&gt;;
</pre></blockquote>
<p>
This deduction guide should be updated to preserve the consistency of
design.
</p>

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

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


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/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> as indicated:</p>

<blockquote>
<pre>
[&hellip;]
template&lt;class Duration, class TimeZonePtr, class TimeZonePtr2&gt;
  zoned_time(TimeZonePtr, zoned_time&lt;Duration, TimeZonePtr2&gt;, choose = choose::earliest)
    -&gt; zoned_time&lt;<ins>common_type_t&lt;</ins>Duration<ins>, seconds&gt;</ins>, TimeZonePtr&gt;;
[&hellip;]
</pre>
</blockquote>

</li>
</ol>




<hr>
<h3><a name="3235" href="#3235">3235</a><sup><a href="https://cplusplus.github.io/LWG/issue3235">(i)</a></sup>. <code>parse</code> manipulator without abbreviation is not callable</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-07-10 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <code>parse</code> overload that does not accept the abbreviation but does accept an offset, 
because the expression in the <i>Remarks:</i> clause:
</p>
<blockquote><pre>
from_stream(declval&lt;basic_istream&lt;charT, traits&gt;*&gt;(), fmt.c_str(), tp, nullptr, &amp;offset)
</pre></blockquote>
<p>
is not valid. This is caused by deduction failure for the <tt>basic_string&lt;charT, traits, Alloc&gt;*</tt> 
from <code>nullptr</code> (see <a href="https://gcc.godbolt.org/z/ZIjfwV">this link</a>):
</p>

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

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


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://wg21.link/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.]
</p>
</blockquote>

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

<blockquote>
<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> 
</p>
<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>
<p>
is <del>a valid</del><ins>well-formed</ins> <del>expression</del><ins>when treated as an unevaluated operand</ins>.
<p/>
-7- <i>Returns:</i> A manipulator that, when extracted from a <tt>basic_istream&lt;charT, traits&gt; is</tt>, 
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>
</li>
</ol>




<hr>
<h3><a name="3241" href="#3241">3241</a><sup><a href="https://cplusplus.github.io/LWG/issue3241">(i)</a></sup>. <tt>chrono-spec</tt> grammar ambiguity in &sect;[time.format]</h3>
<p><b>Section:</b> 27.12 <a href="https://wg21.link/time.format">[time.format]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Victor Zverovich <b>Opened:</b> 2019-07-24 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.format">active issues</a> in [time.format].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.format">issues</a> in [time.format].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>chrono-spec</tt> grammar introduced by <a href="http://wg21.link/p1361r2">P1361R2</a> "Integration 
of chrono with text formatting" in section [time.format] is ambiguous because <tt>'%'</tt> can be 
interpreted as either <tt>literal-char</tt> or <tt>conversion-spec</tt>:
</p>
<blockquote><pre>
chrono-spec     ::= literal-char | conversion-spec
literal-char    ::= &lt;a character other than '{' or '}'&gt;
conversion-spec ::= '%' [modifier] type
</pre></blockquote>

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

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


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

<ol>
<li><p>Modify the <tt>literal-char</tt> grammar in 27.12 <a href="https://wg21.link/time.format">[time.format]</a> as indicated:</p>

<blockquote>
<pre>
<i>literal-char:</i>
          <span style="font-family: serif;">any character other than</span> <tt>{</tt><ins><span style="font-family: serif;">,</span></ins><del> or</del> <tt>}</tt><ins><span style="font-family: serif;">, or</span> %</ins>
</pre>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3244" href="#3244">3244</a><sup><a href="https://cplusplus.github.io/LWG/issue3244">(i)</a></sup>. Constraints for <tt>Source</tt> in &sect;[fs.path.req] insufficiently constrainty</h3>
<p><b>Section:</b> 29.11.7.3 <a href="https://wg21.link/fs.path.req">[fs.path.req]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2019-08-02 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::filesystem::path</tt> has a number of functions - notably including a conversion
constructor template (29.11.7.4.1 <a href="https://wg21.link/fs.path.construct">[fs.path.construct]</a>) and assignment operator template
(29.11.7.4.2 <a href="https://wg21.link/fs.path.assign">[fs.path.assign]</a>) - that accept <tt>const Source&amp;</tt>. Per
29.11.7.3 <a href="https://wg21.link/fs.path.req">[fs.path.req]</a> paragraph 2:
</p><blockquote><p>
-2- Functions taking template parameters named <tt>Source</tt> shall not participate in overload
resolution unless either
</p><p>
(2.1) &mdash; <tt>Source</tt> is a specialization of <tt>basic_string</tt> or
<tt>basic_string_view</tt>, or
</p><p>
(2.2) &mdash; the <i>qualified-id</i>
<tt>iterator_traits&lt;decay_t&lt;Source&gt;&gt;::value_type</tt> is valid and denotes a possibly
<tt>const</tt> encoded character type.
</p></blockquote><p>
<tt>iterator_traits&lt;decay_t&lt;path&gt;&gt;::value_type</tt> is not valid in C++17, so this
specification was sufficient to guard against the conversion constructor template (respectively
assignment operator template) "pretending" to be copy constructor (respectively copy assignment
operator). <a href="https://wg21.link/p0896r4">P0896R4 "The One Ranges Proposal"</a>, however,
altered the definition of <tt>iterator_traits</tt> in the working draft. It now has some convenient
default behaviors for types that meet (roughly) the syntax of the <i><tt>Cpp17InputIterator</tt></i>
requirements. Notably those requirements include copy construction and copy assignment.
</p><p>
In the working draft, to determine the copyability of <tt>std::filesystem::path</tt> we must perform
overload resolution to determine if we can initialize a <tt>path</tt> from a constant lvalue of type
<tt>path</tt>. The conversion constructor template that accepts <tt>const Source&amp;</tt> is a
candidate, since its second argument is defaulted, so
we must perform template argument deduction to see if this constructor is viable. <tt>Source</tt> is
deduced to <tt>path</tt> and we then must check the constraint from 29.11.7.3 <a href="https://wg21.link/fs.path.req">[fs.path.req]</a>
paragraph 2.2 (above). Checking the constraint requires us to specialize
<tt>iterator_traits&lt;path&gt;</tt>, which (per 23.3.2.3 <a href="https://wg21.link/iterator.traits">[iterator.traits]</a> paragraph 3.2)
requires us to determine if <tt>path</tt> satisfies the exposition-only
<i><tt>cpp17-input-iterator</tt></i> concept, which requires <tt>path</tt> to be copyable.
</p><p>
We've completed a cycle: determining if <tt>path</tt> is copyable requires us to first determine if
<tt>path</tt> is copyable. This unfortunate constraint recursion can be broken by explicitly
specifying that <tt>path</tt> is not a valid <tt>Source</tt>.
</p>

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

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


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

<ol>
<li><p>Modify 29.11.7.3 <a href="https://wg21.link/fs.path.req">[fs.path.req]</a> as indicated:</p>
<blockquote><p>
-2- Functions taking template parameters named <tt>Source</tt> shall not participate in overload
resolution unless <ins><tt>Source</tt> denotes a type other than <tt>path</tt>, and</ins> either
</p><p>
[&hellip;]
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="3245" href="#3245">3245</a><sup><a href="https://cplusplus.github.io/LWG/issue3245">(i)</a></sup>. Unnecessary restriction on <tt>'%p'</tt> parse specifier</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tomasz Kami&nacute;ski <b>Opened:</b> 2019-07-31 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification for the <tt>'%p'</tt> flag in "[tab:time.parse.spec]
Meaning of <code>parse</code> flags" places a restriction of it's
placement with regards to the <tt>'%I'</tt> command:
</p>
<blockquote><p>
The locale's equivalent of the AM/PM designations associated with a 12-hour clock.
The command <tt>%I</tt> must precede <tt>%p</tt> in the format string.
</p></blockquote>
<p>
This restriction makes the migration to new API more difficult, as it is
not present for the <a href="http://pubs.opengroup.org/onlinepubs/9699919799/functions/strptime.html">POSIX 
<tt>strptime</tt></a>
nor in the <a href="https://wandbox.org/permlink/nL6dxSSTVzd9zhZ0">example implementation</a> of the 
library. Per Howard's comment:
</p>
<blockquote style="border-left: 3px solid #ccc;padding-left: 15px;">
Actually this is an obsolete requirement and it should be struck. The
first time I implemented this I didn't know how to do it without this
requirement. I've since reimplemented it without needing this.
</blockquote>

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

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


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

<ol>
<li><p>Modify 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>%p</tt>
</td>
<td>
The locale's equivalent of the AM/PM designations associated with a 12-hour clock.
<del>The command <tt>%I</tt> must precede <tt>%p</tt> in the format string.</del>
</td>
</tr>

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



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





<hr>
<h3><a name="3246" href="#3246">3246</a><sup><a href="https://cplusplus.github.io/LWG/issue3246">(i)</a></sup>. What are the constraints on the template parameter of <tt>basic_format_arg</tt>?</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2019-08-01 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In <a href="http://wg21.link/p0645r10">P0645R10</a> 20.?.5.1/ we find:
</p>
<blockquote><p>
<i>Constraints:</i> <tt>typename Context::template formatter_type&lt;T&gt;</tt> is enabled.
</p></blockquote>
<p>
&hellip; which doesn't mean anything, because that is an arbitrary type. Presumably the intent 
is that that type will always be a specialization of formatter, but there appear to be 
no constraints whatsoever on the <tt>Context</tt> template parameter, so there seems to be no 
requirement that that is the case.
<p/>
Should <tt>basic_format_arg</tt> place some constraints on its <tt>Context</tt> template parameter? 
E.g., should it be required to be a specialization of <tt>basic_format_context</tt>?
<p/>
<b>Victor Zverovich:</b>
<p/>
The intent here is to allow different context types provide their own formatter extension types. 
The default formatter context and extension are <tt>basic_format_context</tt> and formatter 
respectively, but it's possible to have other. For example, in the <tt>fmt</tt> library there 
is a formatter context that supports <tt>printf</tt> formatting for legacy code. It cannot use 
the default formatter specializations because of the different syntax <tt>(%...</tt> vs 
<tt>{...})</tt>.
<p/>
<b>Richard Smith:</b>
<p/>
In either case, the specification here seems to be missing the rules for what is a valid 
<tt>Context</tt> parameter.
<p/>
I'm happy to editorially change "is enabled" to "is an enabled specialization of formatter", 
since there's nothing else that this could mean, but we still need a wording fix for the 
broader issue here. Here's what I have so far for this wording:
</p>
<blockquote><p>
<i>Constraints:</i> The template specialization <tt>typename Context::template 
formatter_type&lt;T&gt;</tt> is an enabled specialization of formatter 
([formatter.requirements]).
</p></blockquote>
<p>
<b>Tim Song:</b>
<p/>
I think what we actually want here is "<tt>typename Context::template formatter_type&lt;T&gt;</tt> 
meets the <i>Formatter</i> requirements".
</p>

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

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


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

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

<blockquote>
<pre>
template&lt;class T&gt; explicit basic_format_arg(const T&amp; v) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Constraints:</i> The template specialization
</p>
<blockquote>
<pre>
typename Context::template formatter_type&lt;T&gt;
</pre>
</blockquote>
<p>
<del>is an enabled specialization of <tt>formatter</tt></del><ins>meets the
<i>Formatter</i> requirements</ins> (20.20.4 <a href="https://wg21.link/format.formatter">[format.formatter]</a>). The extent 
to which an implementation determines that the specialization <del>is 
enabled</del><ins>meets the <i>Formatter</i> requirements</ins> is unspecified, 
except that as a minimum the expression
</p>
<blockquote>
<pre>
typename Context::template formatter_type&lt;T&gt;()
  .format(declval&lt;const T&amp;&gt;(), declval&lt;Context&amp;&gt;())
</pre>
</blockquote>
<p>
shall be well-formed when treated as an unevaluated operand.
</p>
</blockquote>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="3253" href="#3253">3253</a><sup><a href="https://cplusplus.github.io/LWG/issue3253">(i)</a></sup>. <tt>basic_syncbuf::basic_syncbuf()</tt> should not be explicit</h3>
<p><b>Section:</b> 29.10.2.1 <a href="https://wg21.link/syncstream.syncbuf.overview">[syncstream.syncbuf.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Nevin Liber <b>Opened:</b> 2019-08-06 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
When <a href="http://wg21.link/p0935">P0935</a> "Eradicating unnecessarily explicit default 
constructors from the standard library" was applied, <tt>basic_syncbuf</tt> was not in the 
working paper. <tt>basic_syncbuf</tt> should not have an explicit default constructor.
</p>

<p><i>[2019-09-02 Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Modify 29.10.2.1 <a href="https://wg21.link/syncstream.syncbuf.overview">[syncstream.syncbuf.overview]</a>, class template <tt>basic_syncbuf</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Allocator&gt;
class basic_syncbuf : public basic_streambuf&lt;charT, traits&gt; {
public:
  [&hellip;]
  <i>// 29.10.2.2 <a href="https://wg21.link/syncstream.syncbuf.cons">[syncstream.syncbuf.cons]</a>, construction and destruction</i>
  <ins>basic_syncbuf()
    : basic_syncbuf(nullptr) {}</ins>
  explicit basic_syncbuf(streambuf_type* obuf <del>= nullptr</del>)
    : basic_syncbuf(obuf, Allocator()) {}
  [&hellip;]
};
</pre>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3256" href="#3256">3256</a><sup><a href="https://cplusplus.github.io/LWG/issue3256">(i)</a></sup>. Feature testing macro for <tt>constexpr</tt> algorithms</h3>
<p><b>Section:</b> 17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Antony Polukhin <b>Opened:</b> 2019-08-14 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.limits.general">active issues</a> in [support.limits.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.limits.general">issues</a> in [support.limits.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Feature testing macro from <a href="http://wg21.link/p0202">P0202</a> "Add Constexpr Modifiers to Functions 
in <tt>&lt;algorithm&gt;</tt> and <tt>&lt;utility&gt;</tt> Headers" is missing in the WD.
<p/>
For user convenience and to reduce feature testing macro count it would be better to stick to initial version 
of P0202 that was providing only the <tt>__cpp_lib_constexpr_algorithms</tt>.
<p/>
So remove <tt>__cpp_lib_constexpr_swap_algorithms</tt>, define <tt>__cpp_lib_constexpr_algorithms</tt> to 
<tt>201703L</tt> if <a href="http://wg21.link/p0202">P0202</a> is implemented, to <tt>201806L</tt> if 
<a href="http://wg21.link/p0202">P0202</a>+<a href="http://wg21.link/p0879">P0879</a> are implemented.
</p>

<p><i>[2019-09-02 Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Modify the Table 36 "Standard library feature-test macros" [tab:support.ft] in 
17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 36: Standard library feature-test macros [tab:support.ft]</caption>
<tr align="center">
<th>Macro name</th>
<th>Value</th>
<th>Header(s)</th>
</tr> 

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

<tr>
<td>
<tt>__cpp_lib_constexpr_<del>swap_</del>algorithms</tt>
</td>
<td>
<tt>201806L</tt>
</td>
<td>
<tt>&lt;algorithm&gt;</tt>
</td>
</tr>

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

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

</ol>




<hr>
<h3><a name="3257" href="#3257">3257</a><sup><a href="https://cplusplus.github.io/LWG/issue3257">(i)</a></sup>. Missing feature testing macro update from P0858</h3>
<p><b>Section:</b> 17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Antony Polukhin <b>Opened:</b> 2019-08-14 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.limits.general">active issues</a> in [support.limits.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.limits.general">issues</a> in [support.limits.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="http://wg21.link/p0858">P0858</a> "Constexpr iterator requirements" suggested to update 
the feature-testing macros <tt>__cpp_lib_string_view</tt> and <tt>__cpp_lib_array_constexpr</tt> 
to the date of adoption.
<p/>
That did not happen.
</p>

<p><i>[2019-09-02 Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Modify the Table 36 "Standard library feature-test macros" [tab:support.ft] in 
17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 36: Standard library feature-test macros [tab:support.ft]</caption>
<tr align="center">
<th>Macro name</th>
<th>Value</th>
<th>Header(s)</th>
</tr> 

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

<tr>
<td>
<tt>__cpp_lib_array_constexpr</tt>
</td>
<td>
<tt>201<del>6</del><ins>8</ins>03L</tt>
</td>
<td>
<tt>&lt;iterator&gt; &lt;array&gt;</tt>
</td>
</tr>

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

<tr>
<td>
<tt>__cpp_lib_string_view</tt>
</td>
<td>
<tt>201<del>606</del><ins>803</ins>L</tt>
</td>
<td>
<tt>&lt;string&gt; &lt;string_view&gt;</tt>
</td>
</tr>

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

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

</ol>




<hr>
<h3><a name="3259" href="#3259">3259</a><sup><a href="https://cplusplus.github.io/LWG/issue3259">(i)</a></sup>. The definition of <i>constexpr iterators</i> should be adjusted</h3>
<p><b>Section:</b> 23.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2019-08-18 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.requirements.general">active issues</a> in [iterator.requirements.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.requirements.general">issues</a> in [iterator.requirements.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current definition of <i>constexpr iterators</i> is specified in 
23.3.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a> p16 as follows:
</p>
<blockquote>
<p>
Iterators are called <i>constexpr iterators</i> if all operations provided to 
meet iterator category requirements are constexpr functions, except for
</p>
<ol style="list-style-type: none">
<li><p>(16.1) &mdash; a pseudo-destructor call (7.5.4.3 <a href="https://wg21.link/expr.prim.id.dtor">[expr.prim.id.dtor]</a>), and</p></li>
<li><p>(16.2) &mdash; the construction of an iterator with a singular value.</p></li>
</ol>
</blockquote>
<p>
With the acceptance of some proposals during the Cologne 2019 meeting, these additional 
requirements become mostly obsolete, as it had already been pointed out during that meeting:
<p/>
With the acceptance of <a href="http://wg21.link/p0784r7">P0784R7</a>, destructors can be 
declared <tt>constexpr</tt> and it is possible to perform a pseudo-destructor call within a 
constant expression, so bullet (16.1) is no longer a necessary requirement.
<p/>
With the acceptance of <a href="http://wg21.link/p1331r2">P1331R2</a>, trivial default 
initialization in constexpr contexts is now possible, and there is no longer a requirement
to initialize all sub-objects of a class object within a constant expression.
<p/>
It seems to me that we should simply strike the above two constraining requirements of the
definition of <i>constexpr iterators</i> for C++20.
</p>

<p><i>[2019-09-14 Issue Prioritization]</i></p>

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


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

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

<blockquote>
<p>
-16- Iterators are called <i>constexpr iterators</i> if all operations provided to 
meet iterator category requirements are constexpr functions<ins>.</ins><del>, except for</del>
</p>
<ol style="list-style-type: none">
<li><p><del>(16.1) &mdash; a pseudo-destructor call (7.5.4.3 <a href="https://wg21.link/expr.prim.id.dtor">[expr.prim.id.dtor]</a>), and</del></p></li>
<li><p><del>(16.2) &mdash; the construction of an iterator with a singular value.</del></p></li>
</ol>
</blockquote>
</li>

</ol>




<hr>
<h3><a name="3266" href="#3266">3266</a><sup><a href="https://cplusplus.github.io/LWG/issue3266">(i)</a></sup>. <tt>to_chars(bool)</tt> should be deleted</h3>
<p><b>Section:</b> 20.19.1 <a href="https://wg21.link/charconv.syn">[charconv.syn]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jens Maurer <b>Opened:</b> 2019-08-23 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.19.2 <a href="https://wg21.link/charconv.to.chars">[charconv.to.chars]</a> does not present an overload for <tt>bool</tt>
(because it is neither a signed nor unsigned integer type), so an attempt to call 
<tt>to_chars</tt> with a bool argument would promote it to <tt>int</tt> and 
unambiguously call the <tt>int</tt> overload of <tt>to_chars</tt>.
<p/>
This was not intended, since it is not obvious that the correct textual representation 
of a <tt>bool</tt> is <tt>0/1</tt> (as opposed to, say, <tt>"true"/"false"</tt>).
<p/>
The user should cast explicitly if he wants the <tt>0/1</tt> behavior. (Correspondingly, 
there is no <tt>bool</tt> overload for <tt>from_chars</tt> in the status quo, and 
conversions do not apply there because of the reference parameter.)
</p>

<p><i>[2019-09-14 Issue Prioritization]</i></p>

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


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

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

<blockquote>
<pre>
[&hellip;]
<i>// 20.19.2 <a href="https://wg21.link/charconv.to.chars">[charconv.to.chars]</a>, primitive numerical output conversion</i>
struct to_chars_result {
  char* ptr;
  errc ec;
  friend bool operator==(const to_chars_result&amp;, const to_chars_result&amp;) = default;
};

to_chars_result to_chars(char* first, char* last, <i>see below</i> value, int base = 10);
<ins>to_chars_result to_chars(char* first, char* last, bool value, int base = 10) = delete;</ins>
to_chars_result to_chars(char* first, char* last, float value);
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3272" href="#3272">3272</a><sup><a href="https://cplusplus.github.io/LWG/issue3272">(i)</a></sup>. <tt>%I%p</tt> should parse/format <tt>duration</tt> since midnight</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#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2019-09-02 <b>Last modified:</b> 2019-10-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#time.format">active issues</a> in [time.format].</p>
<p><b>View all other</b> <a href="lwg-index.html#time.format">issues</a> in [time.format].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is clear how <tt>"%I%p"</tt> parses and formats time points. What is not clear is how these 
flags interact with durations. We should treat durations as "elapsed time since midnight". For example:
</p>
<blockquote>
<pre>
#include &lt;chrono&gt;
#include &lt;iostream&gt;
#include &lt;string&gt;
#include &lt;sstream&gt;

int main()
{
  using namespace std;
  using namespace std::chrono;
  <i>// Format</i>
  {
    <i>// format time_point with %I%p</i>
    cout &lt;&lt; format("{:%F %I%p}", sys_days{2019_y/August/10}+14h) &lt;&lt; '\n';
  }
  {
    <i>// format duration with %I%p</i>
    cout &lt;&lt; format("{:%I%p}", 14h) &lt;&lt; '\n';
  }

  <i>// Parse</i>
  {
    <i>// Parse %I%p as day-of-year combined with an hour into a time_point</i>
    istringstream in{"2019-08-10 2pm"};
    system_clock::time_point tp;
    in &gt;&gt; parse("%F %I%p", tp);
    cout &lt;&lt; tp &lt;&lt; '\n';
  }
  {
    <i>// Parse %I%p as number of hours into a duration</i>
    istringstream in{"2pm"};
    hours d;
    in &gt;&gt; parse("%I%p", d);
    cout &lt;&lt; d &lt;&lt; '\n';
  }
}
</pre>
</blockquote>
<p>
Output:
</p>
<blockquote>
<pre>
2019-08-10 02PM
02PM
2019-08-10 14:00:00.000000
14h
</pre>
</blockquote>

<p><i>[2019-10 Status set to 'Tentatively Ready' after reflector discussion]</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 27.12 <a href="https://wg21.link/time.format">[time.format]</a> as indicated:</p>

<blockquote>
<p>
-3- Unless explicitly requested, the result of formatting a chrono type does not contain time zone abbreviation
and time zone offset information. If the information is available, the conversion specifiers <tt>%Z</tt> and 
<tt>%z</tt> will format this information (respectively). [<i>Note:</i> If the information is not available and 
a <tt>%Z</tt> or <tt>%z</tt> conversion specifier appears in the <i>chrono-format-spec</i>, an exception of 
type <tt>format_error</tt> is thrown, as described above. &mdash; <i>end note</i>]
<p/>
<ins>-?- If the type being formatted does not contain the information that the format flag needs, an exception 
of type <tt>format_error</tt> is thrown. [<i>Example:</i> A <tt>duration</tt> does not contain enough 
information to format as a <tt>weekday</tt> &mdash; <i>end example</i>]. However if a flag refers to a 
"time of day" (e.g. <tt>%H</tt>, <tt>%I</tt>, <tt>%p</tt>, etc.), then a specialization of <tt>duration</tt> 
is interpreted as the time of day elapsed since midnight.</ins>
</p>
</blockquote>

</li>

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> The modification of 27.13 <a href="https://wg21.link/time.parse">[time.parse]</a> p1 is intended to be non-conflictingly 
mergeable with the change suggested by LWG <a href="lwg-active.html#3269">3269</a> and LWG <a href="lwg-active.html#3271">3271</a> at the same paragraph.]
</p>
</blockquote>

<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>, where <tt>charT</tt> and
<tt>traits</tt> are template parameters in that context.</ins>
<p/>
[&hellip;]
<p/>
-10- All <tt>from_stream</tt> overloads behave as unformatted input functions, except that they have an 
unspecified effect on the value returned by subsequent calls to <tt>basic_istream&lt;&gt;::gcount()</tt>.
Each overload takes a format string containing ordinary characters and flags which have special meaning. 
Each flag begins with a <tt>%</tt>. Some flags can be modified by <tt>E</tt> or <tt>O</tt>. During parsing 
each flag interprets characters as parts of date and time types according to Table [tab:time.parse.spec]. 
Some flags can be modified by a width parameter given as a positive decimal integer called out as 
<tt><i>N</i></tt> below which governs how many characters are parsed from the stream in interpreting the 
flag. All characters in the format string that are not represented in Table [tab:time.parse.spec], except 
for white space, are parsed unchanged from the stream. A white space character matches zero or more white
space characters in the input stream.
<p/>
<ins>-?- If the type being parsed can not represent the information that the format flag refers to, 
<tt>is.setstate(ios_base::failbit)</tt> is called. [<i>Example:</i> A <tt>duration</tt> cannot represent a 
<tt>weekday</tt> &mdash; <i>end example</i>]. However if a flag refers to a "time of day" (e.g. <tt>%H</tt>, 
<tt>%I</tt>, <tt>%p</tt>, etc.), then a specialization of <tt>duration</tt> is parsed as the time of day 
elapsed since midnight.</ins>
</p>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3273" href="#3273">3273</a><sup><a href="https://cplusplus.github.io/LWG/issue3273">(i)</a></sup>. Specify <tt>weekday_indexed</tt> to range of <tt>[0, 7]</tt></h3>
<p><b>Section:</b> 27.8.7.2 <a href="https://wg21.link/time.cal.wdidx.members">[time.cal.wdidx.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Howard Hinnant <b>Opened:</b> 2019-09-02 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
On one hand, we say that if you try to construct a <tt>weekday_indexed</tt> with index 0, 
you get an unspecified index instead (27.8.7.2 <a href="https://wg21.link/time.cal.wdidx.members">[time.cal.wdidx.members]</a>/p1),:
</p>
<blockquote>
<p>
The values held are unspecified if <tt>!wd.ok()</tt> or index is not in the range <tt>[1, 5]</tt>.
</p>
</blockquote>
<p>
OTOH, we take pains to pin down <tt>year_month_weekday</tt>'s conversion to <tt>sys_days</tt> 
when the index is zero (27.8.7.2 <a href="https://wg21.link/time.cal.wdidx.members">[time.cal.wdidx.members]</a>/p19):
</p>
<blockquote>
<p>
If <tt>index()</tt> is <tt>0</tt> the returned <tt>sys_days</tt> represents the date <tt>7</tt> 
days prior to the first <tt>weekday()</tt> of <tt>year()/month()</tt>.
</p>
</blockquote>
<p>
This is inconsistent. We should allow a slightly wider range (say, <tt>[0, 7]</tt>, since you need 
at least 3 bits anyway to represent the 5 distinct valid values, and the <tt>0</tt> value referred 
to by 27.8.7.2 <a href="https://wg21.link/time.cal.wdidx.members">[time.cal.wdidx.members]</a>/p19.
</p>

<p><i>[2019-09-24 Issue Prioritization]</i></p>

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


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

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

<blockquote class="note">
<p>
[<i>Drafting note:</i> As a drive-by fix a cleanup of "Constructs an object of type <tt>weekday_indexed</tt>"
wording has been applied as well. ]
</p>
</blockquote>


<blockquote>
<pre>
constexpr weekday_indexed(const chrono::weekday&amp; wd, unsigned index) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> <del>Constructs an object of type <tt>weekday_indexed</tt> by 
initializing</del><ins>Initializes</ins> <tt>wd_</tt> with <tt>wd</tt> and <tt>index_</tt> with 
<tt>index</tt>. The values held are unspecified if <tt>!wd.ok()</tt> or 
<tt>index</tt> is not in the range <tt>[<del>1</del><ins>0</ins>, <del>5</del><ins>7</ins>]</tt>.
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="3274" href="#3274">3274</a><sup><a href="https://cplusplus.github.io/LWG/issue3274">(i)</a></sup>. Missing feature test macro for <tt>&lt;span&gt;</tt></h3>
<p><b>Section:</b> 17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2019-09-05 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#support.limits.general">active issues</a> in [support.limits.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#support.limits.general">issues</a> in [support.limits.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
There is no feature test macro for <tt>std::span</tt>.
<p/>
For the purposes of SD-6, I think we want two values: <tt>201803L</tt> for the original addition of 
<tt>&lt;span&gt;</tt> by <a href="http://wg21.link/p0122r7">P0122R7</a> (Jacksonville, 2018) and then 
<tt>201902L</tt> for the API changes from <a href="http://wg21.link/p1024r3">P1024R3</a> (Kona, 2019). 
The C++ working draft only needs the newer value.
</p>

<p><i>[2019-09-24 Issue Prioritization]</i></p>

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


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

<ol>
<li><p>Modify the Table 36 "Standard library feature-test macros" [tab:support.ft] in 
17.3.1 <a href="https://wg21.link/support.limits.general">[support.limits.general]</a> as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 36: Standard library feature-test macros [tab:support.ft]</caption>
<tr align="center">
<th>Macro name</th>
<th>Value</th>
<th>Header(s)</th>
</tr> 

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

<tr>
<td>
<ins><tt>__cpp_lib_span</tt></ins>
</td>
<td>
<ins><tt>201902L</tt></ins>
</td>
<td>
<ins><tt>&lt;span&gt;</tt></ins>
</td>
</tr>

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

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





<hr>
<h3><a name="3276" href="#3276">3276</a><sup><a href="https://cplusplus.github.io/LWG/issue3276">(i)</a></sup>. Class <tt>split_view::outer_iterator::value_type</tt> should inherit from <tt>view_interface</tt></h3>
<p><b>Section:</b> 24.7.11.4 <a href="https://wg21.link/range.split.outer.value">[range.split.outer.value]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-09 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is a view. It should have all the view goodies. Suggested priority P1 because it affects ABI.
<p/>
The proposed change has been implemented and tested in range-v3.
</p>

<p><i>[2019-09-24 Issue Prioritization]</i></p>

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


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

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

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

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





<hr>
<h3><a name="3277" href="#3277">3277</a><sup><a href="https://cplusplus.github.io/LWG/issue3277">(i)</a></sup>. Pre-increment on prvalues is not a requirement of <tt>weakly_incrementable</tt></h3>
<p><b>Section:</b> 23.3.4.13 <a href="https://wg21.link/iterator.concept.random.access">[iterator.concept.random.access]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Niebler <b>Opened:</b> 2019-09-09 <b>Last modified:</b> 2019-09-25</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.concept.random.access">active issues</a> in [iterator.concept.random.access].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.concept.random.access">issues</a> in [iterator.concept.random.access].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See 23.3.4.13 <a href="https://wg21.link/iterator.concept.random.access">[iterator.concept.random.access]</a>/2.6, which shows <tt>++</tt> being applied to a prvalue iterator.
<p/>
A similar change has already been made to 24.6.3.2 <a href="https://wg21.link/range.iota.view">[range.iota.view]</a>/4.6.
<p/>
Suggest priority P0 or P1 because it effects the definition of a concept.
</p>

<p><i>[2019-09-24 Issue Prioritization]</i></p>

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


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

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

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





</body>
</html>
