<!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 Rapperswil</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 Rapperswil</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P1082R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2018-05-06 at 19:13:12 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="2139" href="#2139">2139</a><sup><a href="https://cplusplus.github.io/LWG/issue2139">(i)</a></sup>. What is a <em>user-defined</em> type?</h3>
<p><b>Section:</b> 20.5.4.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a>, 22.5 <a href="https://wg21.link/syserr">[syserr]</a>, 23.10.8.1 <a href="https://wg21.link/allocator.uses.trait">[allocator.uses.trait]</a>, 23.14.11.1 <a href="https://wg21.link/func.bind.isbind">[func.bind.isbind]</a>, 23.14.11.2 <a href="https://wg21.link/func.bind.isplace">[func.bind.isplace]</a>, 23.14.15 <a href="https://wg21.link/unord.hash">[unord.hash]</a>, 23.15.7.6 <a href="https://wg21.link/meta.trans.other">[meta.trans.other]</a>, 25.3.1 <a href="https://wg21.link/locale">[locale]</a>, 25.4.1.4 <a href="https://wg21.link/locale.codecvt">[locale.codecvt]</a>, 31.12.1.4 <a href="https://wg21.link/re.regiter.incr">[re.regiter.incr]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Lo&iuml;c Joly <b>Opened:</b> 2012-03-08 <b>Last modified:</b> 2018-03-26</p>
<p><b>Priority: </b>4
</p>
<p><b>View all other</b> <a href="lwg-index.html#namespace.std">issues</a> in [namespace.std].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
The expression "user-defined type" is used in several places in the standard, but I'm not sure what 
it means. More specifically, is a type defined in the standard library a user-defined type?
<p/>
From my understanding of English, it is not. From most of the uses of this term in the standard, it 
seem to be considered as user defined. In some places, I'm hesitant, e.g. 20.5.4.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a> p1:
</p>
<blockquote><p>
A program may add a template specialization for any standard library template to namespace <tt>std</tt> 
only if the declaration depends on a user-defined type and the specialization meets the standard library 
requirements for the original template and is not explicitly prohibited.
</p></blockquote>
<p>
Does it mean we are allowed to add in the namespace <tt>std</tt> a specialization for 
<tt>std::vector&lt;std::pair&lt;T, U&gt;&gt;</tt>, for instance?
<p/>
Additional remarks from the reflector discussion: The traditional meaning of user-defined types refers
to class types and enum types, but the library actually means here user-defined types that are not
(purely) library-provided. Presumably a new term - like <em>user-provided type</em> - should be introduced
and properly defined.
</p>

<p><i>[
2012-10 Portland: Move to Deferred 
]</i></p>


<p>
The issue is real, in that we never define this term and rely on a "know it when I see it"
intuition.  However, there is a fear that any attempt to pin down a definition is more
likely to introduce bugs than solve them - getting the wording for this precisely correct
is likely far more work than we are able to give it.
</p>

<p>
There is unease at simple closing as NAD, but not real enthusiasm to provide wording either.
Move to Deferred as we are not opposed to some motivated individual coming back with full
wording to review, but do not want to go out of our way to encourage someone to work on this
in preference to other issues.
</p>

<p><i>[2014-02-20 Re-open Deferred issues as Priority 4]</i></p>


<p><i>[2015-03-05 Jonathan suggests wording]</i></p>

<p>
I dislike the suggestion to change to "user-provided" type because I already find the 
difference between user-declared / user-provided confusing for special member functions, 
so I think it would be better to use a completely different term. The core language
uses "user-defined conversion sequence" and "user-defined literal" and
similar terms for things which the library provides, so I think we
should not refer to "user" at all to distinguish entities defined
outside the implementation from things provided by the implementation.
<p/>
I propose "program-defined type" (and "program-defined specialization"), defined below. 
The P/R below demonstrates the scope of the changes required, even if this name isn't adopted. 
I haven't proposed a change for "User-defined facets" in [locale].
</p>

<p><i>[Lenexa 2015-05-06]</i></p>

<p>RS, HT: The core language uses "user-defined" in a specific way, including library things but excluding core language things, let's use a different term.</p>
<p>MC: Agree.</p>
<p>RS: "which" should be "that", x2</p>
<p>RS: Is std::vector&lt;MyType&gt; a "program-defined type"?</p>
<p>MC: I think it should be.</p>
<p>TK: std::vector&lt;int&gt; seems to take the same path.</p>
<p>JW: std::vector&lt;MyType&gt; isn't program-defined, we don't need it to be, anything that depends on that also depends on =MyType.</p>
<p>TK: The type defined by an "explicit template specialization" should be a program-defined type.</p>
<p>RS: An implicit instantiation of a "program-defined partial specialization" should also be a program-defined type.</p>
<p>JY: This definition formatting is horrible and ugly, can we do better?</p>
<p>RS: Checking ISO directives.</p>
<p>RS: Define "program-defined type" and "program-defined specialization" instead, to get rid of the angle brackets.</p>
<p>JW redrafting.</p>

<p><i>[2017-09-12]</i></p>


<p>Jonathan revises wording as per Lenexa discussion</p>

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

<blockquote class="note">
<p>This wording is relative to N4296.</p>

<ol>
<li><p>Add a new sub-clause to 20.3 <a href="https://wg21.link/definitions">[definitions]</a>:</p>

<p><ins><b>17.3.? [defns.program.defined]</b></ins></p>
<p>
<ins><b>program-defined</b></ins>
<p/>
<ins>&lt;type&gt; a class type or enumeration type which is not part of the C++
standard library and not defined by the implementation. [<i>Note</i>: Types
defined by the implementation include extensions (4.1 <a href="https://wg21.link/intro.compliance">[intro.compliance]</a>)
and internal types used by the library. &mdash; <i>end note</i>]</ins>
</p>
<p>
<ins><b>program-defined</b></ins>
<p/>
<ins>&lt;specialization&gt; an explicit template specialization or partial
specialization which is not part of the C++ standard library and not
defined by the implementation.</ins>
</p>
</li>

<li><p>Change 20.5.4.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a> paragraph 1+2:</p>

<p>
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace <tt>std</tt> or to a
namespace within namespace <tt>std</tt> unless otherwise specified. A program may add a template specialization
for any standard library template to namespace <tt>std</tt> only if the declaration depends on a 
<del>user</del><ins>program</ins>-defined type and the specialization meets the standard library requirements for the 
original template and is not explicitly prohibited.
<p/>
-2- The behavior of a C++ program is undefined if it declares
<p/>
[&hellip;]
<p/>
A program may explicitly instantiate a template defined in the standard library only if the declaration
depends on the name of a <del>user</del><ins>program</ins>-defined type and the instantiation meets the standard 
library requirements for the original template.
</p>
</li>

<li><p>Change 22.5 <a href="https://wg21.link/syserr">[syserr]</a> paragraph 4:</p>

<p>
-4- The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> may be specialized for 
<del>user</del><ins>program</ins>-defined types to indicate that such types are eligible for class <tt>error_code</tt> 
and class <tt>error_condition</tt> automatic conversions, respectively.
</p>
</li>

<li><p>Change 23.10.8.1 <a href="https://wg21.link/allocator.uses.trait">[allocator.uses.trait]</a> paragraph 1:</p>

<p>
-1- <i>Remarks</i>: automatically detects [&hellip;]. A program may specialize this template to derive from 
<tt>true_type</tt> for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> that does not have a nested 
<tt>allocator_type</tt> but nonetheless can be constructed with an allocator where either: [&hellip;]
</p>
</li>

<li><p>Change 23.14.11.1 <a href="https://wg21.link/func.bind.isbind">[func.bind.isbind]</a> paragraph 2:</p>

<p>
-2- Instantiations of the <tt>is_bind_expression</tt> template [&hellip;]. A program may specialize
this template for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt> 
of <tt>true_type</tt> to indicate that <tt>T</tt> should be treated as a subexpression in a <tt>bind</tt> call.
</p>
</li>

<li><p>Change 23.14.11.2 <a href="https://wg21.link/func.bind.isplace">[func.bind.isplace]</a> paragraph 2:</p>

<p>
-2- Instantiations of the <tt>is_placeholder</tt> template [&hellip;]. A program may specialize this template for a 
<del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt> of 
<tt>integral_constant&lt;int, <i>N</i>&gt;</tt> with <tt><i>N</i> &gt; 0</tt> to indicate that <tt>T</tt> should be 
treated as a placeholder type.
</p>
</li>

<li><p>Change 23.14.15 <a href="https://wg21.link/unord.hash">[unord.hash]</a> paragraph 1:</p>

<p>
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> [&hellip;], 
the instantiation <tt>hash&lt;Key&gt;</tt> shall:
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>satisfy the requirement that the expression <tt>h(k)</tt>, where <tt>h</tt> is an object of type 
<tt>hash&lt;Key&gt;</tt> and <tt>k</tt> is an object of type <tt>Key</tt>, shall not throw an exception unless 
<tt>hash&lt;Key&gt;</tt> is a <del>user</del><ins>program</ins>-defined specialization that depends on at least one 
<del>user</del><ins>program</ins>-defined type.</p></li>
</ul>
</li>

<li><p>Change 23.15.7.5 <a href="https://wg21.link/meta.trans.ptr">[meta.trans.ptr]</a> Table 57 (<tt>common_type</tt> row):</p>

<blockquote>
<table border="1">
<caption>Table 57 &mdash; Other transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

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

<tr>
<td>
<tt>template &lt;class... T&gt;<br/>
struct common_type;</tt>
</td>

<td align="center">
&nbsp;
</td>

<td>
The member typedef <tt>type</tt> shall be<br/>
defined or omitted as specified below.<br/>
[&hellip;]. A program may<br/>
specialize this trait if at least one<br/>
template parameter in the<br/>
specialization is a <del>user</del><ins>program</ins>-defined type.<br/>
[&hellip;]
</td>
</tr>

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

</table>
</blockquote>

</li>

<li><p>Change 25.4.1.4 <a href="https://wg21.link/locale.codecvt">[locale.codecvt]</a> paragraph 3:</p>

<p>
-3- The specializations required in Table 81 (22.3.1.1.1) [&hellip;]. Other encodings can be converted 
by specializing on a <del>user</del><ins>program</ins>-defined <tt>stateT</tt> type.[&hellip;]
</p>
</li>

<li><p>Change 31.12.1.4 <a href="https://wg21.link/re.regiter.incr">[re.regiter.incr]</a> paragraph 8:</p>

<p>
-8- [<i>Note</i>: This means that a compiler may call an implementation-specific search function, in which case
a <del>user</del><ins>program</ins>-defined specialization of <tt>regex_search</tt> will not be called. &mdash; 
<i>end note</i>]
</p>
</li>
</ol>
</blockquote>

<p><i>[2018-3-14 Wednesday evening issues processing; move to Ready]</i></p>

<p>After this lands, we need to audit Annex C to find "user-defined type" Example: [diff.cpp03.containers]/3</p>


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

<ol>
<li><p>Add a new sub-clause to 20.3 <a href="https://wg21.link/definitions">[definitions]</a>:</p>

<p><ins><b>20.3.? [defns.program.defined.spec]</b></ins></p>
<p>
<ins><b>program-defined specialization</b></ins>
<p/>
<ins>explicit template specialization or partial
specialization that is not part of the C++ standard library and not
defined by the implementation</ins>
</p>
<p><ins><b>20.3.? [defns.program.defined.type]</b></ins></p>
<p>
<ins><b>program-defined type</b></ins>
<p/>
<ins>class type or enumeration type that is not part of the C++
standard library and not defined by the implementation,
or an instantiation of a program-defined specialization</ins>
</p>
<blockquote class="note">
[<i>Drafting note:</i> ISO directives say the following Note should be labelled as a "Note to entry"
but the C++ WP doesn't follow that rule (yet). &mdash; <i>end drafting note</i>]
</blockquote>
<p><ins> [<i>Note</i>: Types
defined by the implementation include extensions (4.1 <a href="https://wg21.link/intro.compliance">[intro.compliance]</a>)
and internal types used by the library. &mdash; <i>end note</i>]</ins>
</p>
</li>

<li><p>Change 20.5.4.2.1 <a href="https://wg21.link/namespace.std">[namespace.std]</a> paragraph 1+2:</p>

<p>
-1- The behavior of a C++ program is undefined if it adds declarations or definitions to namespace <tt>std</tt> or to a
namespace within namespace <tt>std</tt> unless otherwise specified. A program may add a template specialization
for any standard library template to namespace <tt>std</tt> only if the declaration depends on a 
<del>user</del><ins>program</ins>-defined type and the specialization meets the standard library requirements for the 
original template and is not explicitly prohibited.
<p/>
-2- The behavior of a C++ program is undefined if it declares
<p/>
[&hellip;]
<p/>
A program may explicitly instantiate a template defined in the standard library only if the declaration
depends on the name of a <del>user</del><ins>program</ins>-defined type and the instantiation meets the standard 
library requirements for the original template.
</p>
</li>

<li><p>Change 22.5 <a href="https://wg21.link/syserr">[syserr]</a> paragraph 4:</p>

<p>
-4- The <tt>is_error_code_enum</tt> and <tt>is_error_condition_enum</tt> may be specialized for 
<del>user</del><ins>program</ins>-defined types to indicate that such types are eligible for class <tt>error_code</tt> 
and class <tt>error_condition</tt> automatic conversions, respectively.
</p>
</li>

<li><p>Change 23.10.8.1 <a href="https://wg21.link/allocator.uses.trait">[allocator.uses.trait]</a> paragraph 1:</p>

<p>
-1- <i>Remarks</i>: automatically detects [&hellip;]. A program may specialize this template to derive from 
<tt>true_type</tt> for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> that does not have a nested 
<tt>allocator_type</tt> but nonetheless can be constructed with an allocator where either: [&hellip;]
</p>
</li>

<li><p>Change 23.14.11.1 <a href="https://wg21.link/func.bind.isbind">[func.bind.isbind]</a> paragraph 2:</p>

<p>
-2- Instantiations of the <tt>is_bind_expression</tt> template [&hellip;]. A program may specialize
this template for a <del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt> 
of <tt>true_type</tt> to indicate that <tt>T</tt> should be treated as a subexpression in a <tt>bind</tt> call.
</p>
</li>

<li><p>Change 23.14.11.2 <a href="https://wg21.link/func.bind.isplace">[func.bind.isplace]</a> paragraph 2:</p>

<p>
-2- Instantiations of the <tt>is_placeholder</tt> template [&hellip;]. A program may specialize this template for a 
<del>user</del><ins>program</ins>-defined type <tt>T</tt> to have a <tt>BaseCharacteristic</tt> of 
<tt>integral_constant&lt;int, <i>N</i>&gt;</tt> with <tt><i>N</i> &gt; 0</tt> to indicate that <tt>T</tt> should be 
treated as a placeholder type.
</p>
</li>

<li><p>Change 23.14.15 <a href="https://wg21.link/unord.hash">[unord.hash]</a> paragraph 1:</p>

<p>
The unordered associative containers defined in 23.5 use specializations of the class template <tt>hash</tt> [&hellip;], 
the instantiation <tt>hash&lt;Key&gt;</tt> shall:
</p>
<ul>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>[&hellip;]</p></li>
<li><p>satisfy the requirement that the expression <tt>h(k)</tt>, where <tt>h</tt> is an object of type 
<tt>hash&lt;Key&gt;</tt> and <tt>k</tt> is an object of type <tt>Key</tt>, shall not throw an exception unless 
<tt>hash&lt;Key&gt;</tt> is a <del>user</del><ins>program</ins>-defined specialization that depends on at least one 
<del>user</del><ins>program</ins>-defined type.</p></li>
</ul>
</li>

<li><p>Change 23.15.7.5 <a href="https://wg21.link/meta.trans.ptr">[meta.trans.ptr]</a> Table 57 (<tt>common_type</tt> row):</p>

<blockquote>
<table border="1">
<caption>Table 57 &mdash; Other transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

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

<tr>
<td>
<tt>template &lt;class... T&gt;<br/>
struct common_type;</tt>
</td>

<td align="center">
&nbsp;
</td>

<td>
The member typedef <tt>type</tt> shall be<br/>
defined or omitted as specified below.<br/>
[&hellip;]. A program may<br/>
specialize this trait if at least one<br/>
template parameter in the<br/>
specialization is a <del>user</del><ins>program</ins>-defined type.<br/>
[&hellip;]
</td>
</tr>

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

</table>
</blockquote>

</li>

<li><p>Change 25.4.1.4 <a href="https://wg21.link/locale.codecvt">[locale.codecvt]</a> paragraph 3:</p>

<p>
-3- The specializations required in Table 81 (22.3.1.1.1) [&hellip;]. Other encodings can be converted 
by specializing on a <del>user</del><ins>program</ins>-defined <tt>stateT</tt> type.[&hellip;]
</p>
</li>

<li><p>Change 31.12.1.4 <a href="https://wg21.link/re.regiter.incr">[re.regiter.incr]</a> paragraph 8:</p>

<p>
-8- [<i>Note</i>: This means that a compiler may call an implementation-specific search function, in which case
a <del>user</del><ins>program</ins>-defined specialization of <tt>regex_search</tt> will not be called. &mdash; 
<i>end note</i>]
</p>
</li>
</ol>





<hr>
<h3><a name="2970" href="#2970">2970</a><sup><a href="https://cplusplus.github.io/LWG/issue2970">(i)</a></sup>. Return type of <tt>std::visit</tt> misspecified</h3>
<p><b>Section:</b> 23.7.7 <a href="https://wg21.link/variant.visit">[variant.visit]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2017-05-31 <b>Last modified:</b> 2018-03-05</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#variant.visit">active issues</a> in [variant.visit].</p>
<p><b>View all other</b> <a href="lwg-index.html#variant.visit">issues</a> in [variant.visit].</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>
[variant.visit]/1 correctly uses "type and value category", but then
p3 describes the return type of <tt>visit</tt> to be "the common type of all
possible <tt><i>INVOKE</i></tt> expressions of the <i>Effects:</i> element." 
The type of an expression is never a reference type, due to [expr]/5 removing the
referenceness "prior to any further analysis", so this wording as
written says that <tt>visit</tt> always returns a non-reference type, which is
presumably not the intent.
</p>

<p><i>[2017-07 Toronto Monday issue prioritization]</i></p>

<p>Priority 2; Matt to provide wording</p>

<p><i>[2018-01-11, Thomas K&ouml;ppe comments and suggests wording]</i></p>

<p>
The return type of <tt>std::visit</tt> (originating by <a href="http://wg21.link/p0088r3">P0088R3</a> 
accepted during the Oulo 2016 meeting) is currently misspecified and refers only to the common 
<em>type</em> of all the possible visitation calls, without attention to the value category. This 
seems unintended, and we should preserve the value category.
</p>

<p><i>[2017-01-24, Daniel comments]</i></p>

<p>
This issue should be reviewed in common with LWG <a href="lwg-active.html#3052">3052</a>.
</p>

<p><i>[
2018-02-23 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li><p>Modify 23.7.7 <a href="https://wg21.link/variant.visit">[variant.visit]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class Visitor, class... Variants&gt;
  constexpr <i>see below</i> visit(Visitor&amp;&amp; vis, Variants&amp;&amp;... vars);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Returns:</i> <tt><i>e</i>(<i>m</i>)</tt>, where <tt><i>m</i></tt> is the pack for which 
<tt><i>m<sub>i</sub></i></tt> is <tt>vars<i><sub>i</sub></i>.index()</tt> for all 
<tt>0 &lt;= i &lt; n</tt>. The return type is <del>the type of 
<tt><i>e</i>(<i>m</i>)</tt></del><ins><tt>decltype(<i>e</i>(<i>m</i>))</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3058" href="#3058">3058</a><sup><a href="https://cplusplus.github.io/LWG/issue3058">(i)</a></sup>. Parallel <tt>adjacent_difference</tt> shouldn't require creating temporaries</h3>
<p><b>Section:</b> 29.8.11 <a href="https://wg21.link/adjacent.difference">[adjacent.difference]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2018-02-02 <b>Last modified:</b> 2018-03-26</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#adjacent.difference">issues</a> in [adjacent.difference].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Parallel <tt>adjacent_difference</tt> is presently specified to "create a temporary object whose
type is <tt>ForwardIterator1</tt>'s value type". Serial <tt>adjacent_difference</tt> does that
because it needs to work with input iterators, and needs to work when the destination range
exactly overlaps the input range. The parallel version requires forward iterators and doesn't
allow overlap, so it can avoid making these temporaries.
</p>

<p><i>[2018-02-13, Priority set to 3 after mailing list discussion]</i></p>


<p><i>[2018-3-14 Wednesday evening issues processing; remove 'const' before <tt>minus</tt> and move to Ready.]</i></p>


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

<ol>
<li><p>Modify 29.8.11 <a href="https://wg21.link/adjacent.difference">[adjacent.difference]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator, class OutputIterator&gt;
  OutputIterator
    adjacent_difference(InputIterator first, InputIterator last, OutputIterator result);
template&lt;class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator2
    adjacent_difference(ExecutionPolicy&amp;&amp; exec,
                        ForwardIterator1 first, ForwardIterator1 last, ForwardIterator2 result);

template&lt;class InputIterator, class OutputIterator, class BinaryOperation&gt;
  OutputIterator
    adjacent_difference(InputIterator first, InputIterator last,
                        OutputIterator result, BinaryOperation binary_op);
template&lt;class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2,
         class BinaryOperation&gt;
  ForwardIterator2
    adjacent_difference(ExecutionPolicy&amp;&amp; exec,
                        ForwardIterator1 first, ForwardIterator1 last,
                        ForwardIterator2 result, BinaryOperation binary_op);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be the value type of <tt>decltype(first)</tt>. For the overloads that do not
take an argument <tt>binary_op</tt>, let <tt>binary_op</tt> be an lvalue that denotes an object of
type <tt>const minus&lt;&gt;</tt>.</ins>
</p><p>
-1- <i>Requires:</i>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; For the overloads with no <tt>ExecutionPolicy</tt>,
<del><tt>InputIterator</tt>’s value type</del> <ins><tt>T</tt></ins> shall be
<tt>MoveAssignable</tt> (Table 25) and shall be constructible from the type of <tt>*first</tt>.
<tt>acc</tt> (defined below) shall be writable (27.2.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>) to
the <tt>result</tt> output iterator. The result of the expression <del><tt>val - std::move(acc)</tt>
or</del> <tt>binary_op(val, std::move(acc))</tt> shall be writable to the <tt>result</tt> output
iterator.</p></li>

<li><p>(1.2) &mdash; For the overloads with an <tt>ExecutionPolicy</tt>, the <del>value type of
<tt>ForwardIterator1</tt> shall be <tt>CopyConstructible</tt> (Table 24), constructible from the
expression <tt>*first - *first</tt> or <tt>binary_op(*first, *first)</tt>, and assignable to the
value type of <tt>ForwardIterator2</tt></del><ins>result of the expressions
<tt>binary_op(*first, *first)</tt> and <tt>*first</tt> shall be writable to
<tt>result</tt></ins>.</p></li>

<li><p>(1.3) &mdash; [&hellip;]</p></li>
</ol>
<p/>
-2- <i>Effects:</i> For the overloads with no <tt>ExecutionPolicy</tt> and a non-empty range, the
function creates an accumulator <tt>acc</tt> <del>whose type is <tt>InputIterator</tt>’s value
type</del> <ins>of type <tt>T</tt></ins>, initializes it with <tt>*first</tt>, and assigns the
result to <tt>*result</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order,
creates an object <tt>val</tt> whose type is <del><tt>InputIterator</tt>’s value type</del>
<ins><tt>T</tt></ins>, initializes it with <tt>*i</tt>, computes <del><tt>val - std::move(acc)</tt>
or</del> <tt>binary_op(val, std::move(acc))</tt>, assigns the result to
<tt>*(result + (i - first))</tt>, and move assigns from <tt>val</tt> to <tt>acc</tt>.
<p/>
-3- For the overloads with an <tt>ExecutionPolicy</tt> and a non-empty range, <del>first the function
creates an object whose type is <tt>ForwardIterator1</tt>'s value type, initializes it with
<tt>*first</tt>, and assigns the result to <tt>*result</tt>. Then for every <tt>d</tt> in
<tt>[1, last - first - 1]</tt>, creates an object <tt>val</tt> whose type is
<tt>ForwardIterator1</tt>'s value type, initializes it with <tt>*(first + d) - *(first + d - 1)</tt>
or <tt>binary_op(*(first + d), *(first + d - 1))</tt>, and assigns the result to
<tt>*(result + d)</tt></del><ins>performs <tt>*result = *first</tt>. Then, for every <tt>d</tt> in
<tt>[1, last - first - 1]</tt>, performs
<tt>*(result + d) = binary_op(*(first + d), *(first + (d - 1)))</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>


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

<ol>
<li><p>Modify 29.8.11 <a href="https://wg21.link/adjacent.difference">[adjacent.difference]</a> as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator, class OutputIterator&gt;
  OutputIterator
    adjacent_difference(InputIterator first, InputIterator last, OutputIterator result);
template&lt;class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2&gt;
  ForwardIterator2
    adjacent_difference(ExecutionPolicy&amp;&amp; exec,
                        ForwardIterator1 first, ForwardIterator1 last, ForwardIterator2 result);

template&lt;class InputIterator, class OutputIterator, class BinaryOperation&gt;
  OutputIterator
    adjacent_difference(InputIterator first, InputIterator last,
                        OutputIterator result, BinaryOperation binary_op);
template&lt;class ExecutionPolicy, class ForwardIterator1, class ForwardIterator2,
         class BinaryOperation&gt;
  ForwardIterator2
    adjacent_difference(ExecutionPolicy&amp;&amp; exec,
                        ForwardIterator1 first, ForwardIterator1 last,
                        ForwardIterator2 result, BinaryOperation binary_op);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be the value type of <tt>decltype(first)</tt>. For the overloads that do not
take an argument <tt>binary_op</tt>, let <tt>binary_op</tt> be an lvalue that denotes an object of
type <tt>minus&lt;&gt;</tt>.</ins>
</p><p>
-1- <i>Requires:</i>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; For the overloads with no <tt>ExecutionPolicy</tt>,
<del><tt>InputIterator</tt>’s value type</del> <ins><tt>T</tt></ins> shall be
<tt>MoveAssignable</tt> (Table 25) and shall be constructible from the type of <tt>*first</tt>.
<tt>acc</tt> (defined below) shall be writable (27.2.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>) to
the <tt>result</tt> output iterator. The result of the expression <del><tt>val - std::move(acc)</tt>
or</del> <tt>binary_op(val, std::move(acc))</tt> shall be writable to the <tt>result</tt> output
iterator.</p></li>

<li><p>(1.2) &mdash; For the overloads with an <tt>ExecutionPolicy</tt>, the <del>value type of
<tt>ForwardIterator1</tt> shall be <tt>CopyConstructible</tt> (Table 24), constructible from the
expression <tt>*first - *first</tt> or <tt>binary_op(*first, *first)</tt>, and assignable to the
value type of <tt>ForwardIterator2</tt></del><ins>result of the expressions
<tt>binary_op(*first, *first)</tt> and <tt>*first</tt> shall be writable to
<tt>result</tt></ins>.</p></li>

<li><p>(1.3) &mdash; [&hellip;]</p></li>
</ol>
<p/>
-2- <i>Effects:</i> For the overloads with no <tt>ExecutionPolicy</tt> and a non-empty range, the
function creates an accumulator <tt>acc</tt> <del>whose type is <tt>InputIterator</tt>’s value
type</del> <ins>of type <tt>T</tt></ins>, initializes it with <tt>*first</tt>, and assigns the
result to <tt>*result</tt>. For every iterator <tt>i</tt> in <tt>[first + 1, last)</tt> in order,
creates an object <tt>val</tt> whose type is <del><tt>InputIterator</tt>’s value type</del>
<ins><tt>T</tt></ins>, initializes it with <tt>*i</tt>, computes <del><tt>val - std::move(acc)</tt>
or</del> <tt>binary_op(val, std::move(acc))</tt>, assigns the result to
<tt>*(result + (i - first))</tt>, and move assigns from <tt>val</tt> to <tt>acc</tt>.
<p/>
-3- For the overloads with an <tt>ExecutionPolicy</tt> and a non-empty range, <del>first the function
creates an object whose type is <tt>ForwardIterator1</tt>'s value type, initializes it with
<tt>*first</tt>, and assigns the result to <tt>*result</tt>. Then for every <tt>d</tt> in
<tt>[1, last - first - 1]</tt>, creates an object <tt>val</tt> whose type is
<tt>ForwardIterator1</tt>'s value type, initializes it with <tt>*(first + d) - *(first + d - 1)</tt>
or <tt>binary_op(*(first + d), *(first + d - 1))</tt>, and assigns the result to
<tt>*(result + d)</tt></del><ins>performs <tt>*result = *first</tt>. Then, for every <tt>d</tt> in
<tt>[1, last - first - 1]</tt>, performs
<tt>*(result + d) = binary_op(*(first + d), *(first + (d - 1)))</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3062" href="#3062">3062</a><sup><a href="https://cplusplus.github.io/LWG/issue3062">(i)</a></sup>. Unnecessary <tt>decay_t</tt> in <tt>is_execution_policy_v</tt> should be <tt>remove_cvref_t</tt></h3>
<p><b>Section:</b> 28.4.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2018-02-07 <b>Last modified:</b> 2018-02-20</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Our compiler throughput friends were hissing at us about throughput regressions in C++17 mode caused by 
the addition of the parallel algorithms' signatures. One change to reduce the throughput impact would 
be to remove unnecessary decay here, as LWG has done in other places recently.
</p>

<p><i>[
2018-02-13 Moved to Tentatively Ready after 7 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li><p>Modify 28.4.5 <a href="https://wg21.link/algorithms.parallel.overloads">[algorithms.parallel.overloads]</a> as indicated:</p>

<blockquote>
<p>
-4- Parallel algorithms shall not participate in overload resolution unless 
<tt>is_execution_policy_v&lt;<del>decay</del><ins>remove_cvref</ins>_t&lt;ExecutionPolicy&gt;&gt;</tt> 
is <tt>true</tt>.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3067" href="#3067">3067</a><sup><a href="https://cplusplus.github.io/LWG/issue3067">(i)</a></sup>. <tt>recursive_directory_iterator::pop</tt> must invalidate</h3>
<p><b>Section:</b> 30.11.13.1 <a href="https://wg21.link/fs.rec.dir.itr.members">[fs.rec.dir.itr.members]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2018-02-25 <b>Last modified:</b> 2018-03-13</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.rec.dir.itr.members">active issues</a> in [fs.rec.dir.itr.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.rec.dir.itr.members">issues</a> in [fs.rec.dir.itr.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>recursive_directory_iterator::pop</tt> is effectively a "supercharged" <tt>operator++</tt>: it
advances the iterator forward as many steps as are necessary to reach the next entry in the parent
directory. Just as is the case for <tt>operator++</tt>, <tt>pop</tt> must be allowed to invalidate
iterator copies to allow efficient implementation. The most efficient fix seems to be borrowing the
invalidation wording from 27.2.3 <a href="https://wg21.link/input.iterators">[input.iterators]</a> Table 87's specification for the required
<tt>++r</tt> expression for input iterators.
</p>

<p><i>[
2018-03-06 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li><p>Change 30.11.13.1 <a href="https://wg21.link/fs.rec.dir.itr.members">[fs.rec.dir.itr.members]</a> as indicated:</p>
<blockquote>
<pre>
void pop();
void pop(error_code&amp; ec);
</pre>
<blockquote>
<p>
-26- <i>Effects</i>: If <tt>depth() == 0</tt>, set <tt>*this</tt> to
<tt>recursive_directory_iterator()</tt>. Otherwise, cease iteration of the directory currently being
iterated over, and continue iteration over the parent directory.
</p>
<p>
<ins>-?- <i>Postconditions</i>: Any copies of the previous value of <tt>*this</tt> are no longer
required either to be dereferenceable or to be in the domain of <tt>==</tt>.</ins>
</p>
<p>
-27- <i>Throws</i>: As specified in 30.11.6 <a href="https://wg21.link/fs.err.report">[fs.err.report]</a>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3071" href="#3071">3071</a><sup><a href="https://cplusplus.github.io/LWG/issue3071">(i)</a></sup>. [networking.ts] <tt>read_until</tt> still refers to "input sequence"</h3>
<p><b>Section:</b> 17.9 [networking.ts::buffer.read.until] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Christopher Kohlhoff <b>Opened:</b> 2018-02-26 <b>Last modified:</b> 2018-03-13</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>
<b>Addresses: networking.ts</b>
<p>
When specifying <tt>DynamicBuffers</tt> and their related operations, early drafts of the Networking TS described the buffers in terms of their "input sequence" and "output sequence". This was changed to "readable bytes" and "writable bytes" respectively. Unfortunately, some instances of "input sequence" were missed in section 
17.9 [networking.ts::buffer.read.until].
</p>

<p><i>[
2018-03-06 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li><p>Change 17.9 [networking.ts::buffer.read.until] as indicated:</p>
<blockquote>
<pre>
template&lt;class SyncReadStream, class DynamicBuffer&gt;
  size_t read_until(SyncReadStream&amp; s, DynamicBuffer&amp;&amp; b, char delim);
template&lt;class SyncReadStream, class DynamicBuffer&gt;
  size_t read_until(SyncReadStream&amp; s, DynamicBuffer&amp;&amp; b,
                    char delim, error_code&amp; ec);
template&lt;class SyncReadStream, class DynamicBuffer&gt;
  size_t read_until(SyncReadStream&amp; s, DynamicBuffer&amp;&amp; b, string_view delim);
template&lt;class SyncReadStream, class DynamicBuffer&gt;
  size_t read_until(SyncReadStream&amp; s, DynamicBuffer&amp;&amp; b,
                    string_view delim, error_code&amp; ec);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Reads data from the buffer-oriented synchronous read stream 
(17.1.1 [networking.ts::buffer.stream.reqmts.syncreadstream]) object stream by performing zero or more 
calls to the stream's <tt>read_some</tt> member function, until the 
<del>input sequence</del><ins>readable bytes</ins> of the dynamic buffer 
(16.2.4 [networking.ts::buffer.reqmts.dynamicbuffer]) object <tt>b</tt> contain<del>s</del> the specified 
delimiter <tt>delim</tt>.
<p/>
-2- Data is placed into the dynamic buffer object b. A mutable buffer sequence (16.2.1) is obtained 
prior to each <tt>read_some</tt> call using <tt>b.prepare(N)</tt>, where <tt>N</tt> is an unspecified 
value such that <tt>N &lt;= max_size() - size()</tt>. [<i>Note:</i> Implementations are encouraged to use
<tt>b.capacity()</tt> when determining <tt>N</tt>, to minimize the number of <tt>read_some</tt>
calls performed on the stream. &mdash; <i>end note</i>] After each <tt>read_some</tt> call, 
the implementation performs <tt>b.commit(n)</tt>, where <tt>n</tt> is the return value from
<tt>read_some</tt>.
<p/>
-3- The synchronous <tt>read_until</tt> operation continues until:
<ol style="list-style-type: none">
<li><p>(3.1) &mdash; the <del>input sequence</del><ins>readable bytes</ins> of <tt>b</tt> contain<del>s</del> 
the delimiter <tt>delim</tt>; or</p></li>
<li><p>(3.2) &mdash; <tt>b.size() == b.max_size()</tt>; or</p></li>
<li><p>(3.3) &mdash; an asynchronous <tt>read_some</tt> operation fails.</p></li>
</ol>
<p/>
-4- On exit, if the <del>input sequence</del><ins>readable bytes</ins> of <tt>b</tt> contain<del>s</del> 
the delimiter, <tt>ec</tt> is set such that <tt>!ec</tt> is <tt>true</tt>. Otherwise, if 
<tt>b.size() == b.max_size()</tt>, <tt>ec</tt> is set such that <tt>ec == stream_errc::not_found</tt>. 
If <tt>b.size() &lt; b.max_size()</tt>, <tt>ec</tt> contains the <tt>error_code</tt> from the most 
recent <tt>read_some</tt> call.
<p/>
-5- <i>Returns:</i> The number of <del>bytes in the input sequence of</del><ins>readable bytes in</ins> 
<tt>b</tt> up to and including the delimiter, if present. [<i>Note:</i> On completion, the buffer may 
contain additional bytes following the delimiter. &mdash; <i>end note</i>] Otherwise returns <tt>0</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3074" href="#3074">3074</a><sup><a href="https://cplusplus.github.io/LWG/issue3074">(i)</a></sup>. Non-member functions for <tt>valarray</tt> should only deduce from the <tt>valarray</tt></h3>
<p><b>Section:</b> 29.7.3 <a href="https://wg21.link/valarray.nonmembers">[valarray.nonmembers]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2018-02-28 <b>Last modified:</b> 2018-03-13</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 expression <tt>(std::valarray&lt;double&gt;{} * 2)</tt> is ill-formed, because argument deduction 
fails for:</p>
<blockquote><pre>
template&lt;class T&gt;
  valarray&lt;T&gt; operator*(const valarray&lt;T&gt;&amp;, const T&amp;);
</pre></blockquote>
<p>
Is there any reason to try and deduce the argument from the scalar, instead of only deducing from the valarray and allowing implicit conversions to the scalar? i.e.
</p>
<blockquote><pre>
template&lt;class T&gt; 
  valarray&lt;T&gt; operator*(const valarray&lt;T&gt;&amp;, const typename valarray&lt;T&gt;::value_type&amp;);
</pre></blockquote>

<p><i>[
2018-03-07 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li>
<p>Edit 29.7.1 <a href="https://wg21.link/valarray.syn">[valarray.syn]</a>, header <tt>&lt;valarray&gt;</tt> synopsis, as indicated:</p>
<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt; valarray&lt;T&gt; operator* (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator* (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator* (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator/ (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator/ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator/ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator% (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator% (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator% (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator+ (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator+ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator+ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator- (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator- (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator- (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator^ (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator^ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator^ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator&amp; (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&amp; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&amp; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator| (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator| (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator| (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator&lt;&lt;(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&lt;&lt;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&lt;&lt;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; operator&gt;&gt;(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&gt;&gt;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&gt;&gt;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator&amp;&amp;(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&amp;&amp;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&amp;&amp;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator||(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator||(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator||(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator==(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator==(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator==(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator!=(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator!=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator!=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator&lt; (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator&gt; (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator&lt;=(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt;=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt;=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;bool&gt; operator&gt;=(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt;=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt;=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; abs (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; acos (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; asin (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan (const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; atan2(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan2(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan2(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; cos (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; cosh (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; exp (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; log (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; log10(const valarray&lt;T&gt;&amp;);

template&lt;class T&gt; valarray&lt;T&gt; pow(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; pow(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; pow(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
[&hellip;]
</pre>
</blockquote>
</li>

<li>
<p>Edit 29.7.3.1 <a href="https://wg21.link/valarray.binary">[valarray.binary]</a> as indicated:</p>
<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt; valarray&lt;T&gt; operator* (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator* (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator/ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator/ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator% (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator% (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator+ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator+ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator- (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator- (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator^ (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator^ (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&amp; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&amp; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator| (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator| (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&lt;&lt;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&lt;&lt;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&gt;&gt;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; operator&gt;&gt;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
[&hellip;]
</pre>
</blockquote>
</li>

<li>
<p>Edit 29.7.3.2 <a href="https://wg21.link/valarray.comparison">[valarray.comparison]</a> as indicated:</p>
<blockquote>
<pre>
[&hellip;]
template&lt;class T&gt; valarray&lt;bool&gt; operator==(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator==(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator!=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator!=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt; (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt; (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt;=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&lt;=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt;=(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&gt;=(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&amp;&amp;(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator&amp;&amp;(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator||(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;bool&gt; operator||(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
[&hellip;]
</pre>
</blockquote>
</li>

<li>
<p>Edit 29.7.3.3 <a href="https://wg21.link/valarray.transcend">[valarray.transcend]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class T&gt; valarray&lt;T&gt; abs (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; acos (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; asin (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan2(const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan2(const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; atan2(const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; cos (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; cosh (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; exp (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; log (const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; log10(const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; pow (const valarray&lt;T&gt;&amp;, const valarray&lt;T&gt;&amp;);
template&lt;class T&gt; valarray&lt;T&gt; pow (const valarray&lt;T&gt;&amp;, const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;);
template&lt;class T&gt; valarray&lt;T&gt; pow (const <del>T</del><ins>typename valarray&lt;T&gt;::value_type</ins>&amp;, const valarray&lt;T&gt;&amp;);
[&hellip;]
</pre>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3076" href="#3076">3076</a><sup><a href="https://cplusplus.github.io/LWG/issue3076">(i)</a></sup>. <tt>basic_string</tt> CTAD ambiguity</h3>
<p><b>Section:</b> 24.3.2.2 <a href="https://wg21.link/string.cons">[string.cons]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2018-03-03 <b>Last modified:</b> 2018-03-26</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The following code fails to compile for surprising reasons.
</p>
<blockquote><pre>
#include &lt;string&gt;
#include &lt;string_view&gt;

using namespace std;

int main() 
{
   string s0;
   basic_string s1(s0, 1, 1);
   // WANT: basic_string(const basic_string&amp;, size_type, size_type, const Allocator&amp; = Allocator())
   // CONFLICT: basic_string(size_type, charT, const Allocator&amp;)

   basic_string s2("cat"sv, 1, 1);
   // WANT: basic_string(const T&amp;, size_type, size_type, const Allocator&amp; = Allocator())
   // CONFLICT: basic_string(size_type, charT, const Allocator&amp;)

   basic_string s3("cat", 1);
   // WANT: basic_string(const charT *, size_type, const Allocator&amp; = Allocator())
   // CONFLICT: basic_string(const charT *, const Allocator&amp;)
}
</pre></blockquote>
<p>
For <tt>s1</tt> and <tt>s2</tt>, the signature <tt>basic_string(size_type, charT, const Allocator&amp;)</tt> participates in CTAD. <tt>size_type</tt> is non-deduced (it will be substituted later, so the compiler 
can't immediately realize that <tt>s0</tt> or <tt>"cat"sv</tt> are totally non-viable arguments). 
<tt>charT</tt> is deduced to be <tt>int</tt> (weird, but not the problem). Finally, <tt>Allocator</tt> 
is deduced to be <tt>int</tt>. Then the compiler tries to substitute for <tt>size_type</tt>, but 
this ends up giving int to <tt>allocator_traits</tt> in a non-SFINAE context, so compilation fails.
<p/>
<tt>s3</tt> fails for a slightly different reason. <tt>basic_string(const charT *, const Allocator&amp;)</tt> participates in CTAD, deducing <tt>charT</tt> to be <tt>char</tt> (good) and <tt>Allocator</tt> to be 
<tt>int</tt>. This is an exact match, which is better than the constructor that the user actually wants 
(where <tt>int</tt> would need to be converted to <tt>size_type</tt>, which is unsigned). So CTAD deduces <tt>basic_string&lt;char, char_traits&lt;char&gt;, int&gt;</tt>, which is the wrong type.
<p/>
This problem appears to be unique to <tt>basic_string</tt> and its heavily overloaded set of constructors. 
I haven't figured out how to fix it by adding (non-greedy) deduction guides. The conflicting constructors 
are always considered during CTAD, regardless of whether deduction guides are provided that correspond 
to the desired or conflicting constructors. (That's because deduction guides are preferred as a late 
tiebreaker in overload resolution; if a constructor provides a better match it will be chosen before 
tiebreaking.) It appears that we need to constrain the conflicting constructors themselves; this will 
have no effect on actual usage (where <tt>Allocator</tt> will be an allocator) but will prevent CTAD 
from considering them for non-allocators. As this is unusual, I believe it deserves a <i>Note</i>. 
This has been implemented in MSVC.
</p>

<p><i>[2018-3-14 Wednesday evening issues processing; move to Ready]</i></p>



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

<ol>
<li>
<p>Edit 24.3.2.2 <a href="https://wg21.link/string.cons">[string.cons]</a> as indicated:</p>
<blockquote>
<pre>
basic_string(const charT* s, const Allocator&amp; a = Allocator());
</pre>
<blockquote>
<p>
-14- <i>Requires:</i> <tt>s</tt> points to an array of at least <tt>traits::length(s) + 1</tt> elements of 
<tt>charT</tt>.
<p/>
-15- <i>Effects:</i> Constructs an object of class <tt>basic_string</tt> and determines its initial 
string value from the array of <tt>charT</tt> of length <tt>traits::length(s)</tt> whose first element 
is designated by <tt>s</tt>.
<p/>
-16- <i>Postconditions:</i> <tt>data()</tt> points at the first element of an allocated copy of the 
array whose first element is pointed at by <tt>s</tt>, <tt>size()</tt> is equal to <tt>traits::length(s)</tt>, 
and <tt>capacity()</tt> is a value at least as large as <tt>size()</tt>.
<p/>
<ins>-?- <i>Remarks:</i> Shall not participate in overload resolution if <tt>Allocator</tt> is a type 
that does not qualify as an allocator (26.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>). [<i>Note:</i> 
This affects class template argument deduction. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
<pre>
basic_string(size_type n, charT c, const Allocator&amp; a = Allocator());
</pre>
<blockquote>
<p>
-17- <i>Requires:</i> <tt>n &lt; npos</tt>.
<p/>
-18- <i>Effects:</i> Constructs an object of class <tt>basic_string</tt> and determines its initial string 
value by repeating the char-like object <tt>c</tt> for all <tt>n</tt> elements.
<p/>
-19- <i>Postconditions:</i> <tt>data()</tt> points at the first element of an allocated array of <tt>n</tt>
elements, each storing the initial value <tt>c</tt>, <tt>size()</tt> is equal to <tt>n</tt>, and 
<tt>capacity()</tt> is a value at least as large as <tt>size()</tt>.
<p/>
<ins>-?- <i>Remarks:</i> Shall not participate in overload resolution if <tt>Allocator</tt> is a type that 
does not qualify as an allocator (26.2.1 <a href="https://wg21.link/container.requirements.general">[container.requirements.general]</a>). [<i>Note:</i> This 
affects class template argument deduction. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3079" href="#3079">3079</a><sup><a href="https://cplusplus.github.io/LWG/issue3079">(i)</a></sup>. LWG 2935 forgot to fix the <tt>existing_p</tt> overloads of <tt>create_directory</tt></h3>
<p><b>Section:</b> 30.11.14.7 <a href="https://wg21.link/fs.op.create_directory">[fs.op.create_directory]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2018-03-07 <b>Last modified:</b> 2018-03-31</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>
LWG <a href="lwg-defects.html#2935">2935</a> clarified that <tt>create_directory</tt> is not supposed to report an error if 
<tt>exists(p)</tt>, even if <tt>p</tt> is not a directory. However, the P/R there missed the 
<tt>existing_p</tt> overloads.
</p>

<p><i>[
2018-03-27 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li>
<p>Edit 30.11.14.7 <a href="https://wg21.link/fs.op.create_directory">[fs.op.create_directory]</a> as indicated:</p>
<blockquote>
<pre>
bool create_directory(const path&amp; p, const path&amp; existing_p);
bool create_directory(const path&amp; p, const path&amp; existing_p, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> <del>Establishes the postcondition by attempting to create</del><ins>Creates</ins> 
the directory <tt>p</tt> resolves to, with attributes copied from directory <tt>existing_p</tt>. 
The set of attributes copied is operating system dependent. Creation failure because <tt>p</tt> 
<del>resolves to an existing directory shall not be treated as</del><ins>already exists is not</ins> 
an error. [<i>Note:</i> For POSIX-based operating systems, the attributes 
are those copied by native API <tt>stat(existing_p.c_str(), &amp;attributes_stat)</tt> followed by 
<tt>mkdir(p.c_str(), attributes_stat.st_mode)</tt>. For Windows-based operating systems, the attributes 
are those copied by native API <tt>CreateDirectoryExW(existing_p.c_str(), p.c_str(), 0)</tt>. &mdash;
<i>end note</i>]
<p/>
<del>-5- <i>Postconditions:</i> <tt>is_directory(p)</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3080" href="#3080">3080</a><sup><a href="https://cplusplus.github.io/LWG/issue3080">(i)</a></sup>. Floating point <tt>from_chars</tt> pattern specification breaks round-tripping</h3>
<p><b>Section:</b> 23.20.3 <a href="https://wg21.link/charconv.from.chars">[charconv.from.chars]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Greg Falcon <b>Opened:</b> 2018-03-12 <b>Last modified:</b> 2018-03-31</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#charconv.from.chars">active issues</a> in [charconv.from.chars].</p>
<p><b>View all other</b> <a href="lwg-index.html#charconv.from.chars">issues</a> in [charconv.from.chars].</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>from_chars</tt> specifies that the <tt>'+'</tt> character is never matched, but <tt>to_chars</tt> 
specifies its output format in terms of <tt>printf()</tt>, which puts a <tt>'+'</tt> sign before 
positive exponents.
<p/>
Since <tt>strtod()</tt> matches <tt>'+'</tt> signs, it is also desirable to accept <tt>'+'</tt> in 
exponents, so that code currently using <tt>strtod()</tt> can be migrated to <tt>from_chars()</tt> 
without a breaking semantic change.
</p>

<p><i>[
2018-03-27 Moved to Tentatively Ready after 9 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li>
<p>Edit 23.20.3 <a href="https://wg21.link/charconv.from.chars">[charconv.from.chars]</a> as indicated:</p>
<blockquote>
<pre>
from_chars_result from_chars(const char* first, const char* last, float&amp; value,
                             chars_format fmt = chars_format::general);
from_chars_result from_chars(const char* first, const char* last, double&amp; value,
                             chars_format fmt = chars_format::general);
from_chars_result from_chars(const char* first, const char* last, long double&amp; value,
                             chars_format fmt = chars_format::general);
</pre>
<blockquote>
<p>
-6- <i>Requires:</i> <tt>fmt</tt> has the value of one of the enumerators of <tt>chars_format</tt>.
<p/>
-7- <i>Effects:</i> The pattern is the expected form of the subject sequence in the <tt>"C"</tt> 
locale, as described for <tt>strtod</tt>, except that
</p>
<ol style="list-style-type: none">
<li><p>(7.1) &mdash; the <del>only</del> sign <ins><tt>'+'</tt></ins> <del>that</del> may <ins>only</ins> 
appear <del>is <tt>'-'</tt></del><ins>in the exponent part</ins>;</p></li>
<li><p>(7.2) [&hellip;]</p></li>
<li><p>(7.3) [&hellip;]</p></li>
<li><p>(7.4) [&hellip;]</p></li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3083" href="#3083">3083</a><sup><a href="https://cplusplus.github.io/LWG/issue3083">(i)</a></sup>. What should <tt>ios::iword(-1)</tt> do?</h3>
<p><b>Section:</b> 30.5.3.5 <a href="https://wg21.link/ios.base.storage">[ios.base.storage]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2018-03-16 <b>Last modified:</b> 2018-03-31</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#ios.base.storage">active issues</a> in [ios.base.storage].</p>
<p><b>View all other</b> <a href="lwg-index.html#ios.base.storage">issues</a> in [ios.base.storage].</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>
Is calling <tt>iword</tt> and <tt>pword</tt> with a negative argument undefined, or should it cause 
a failure condition (and return a valid reference)? What about <tt>INT_MAX</tt>? What about <tt>0</tt>?
<p/>
Using arbitrary indices isn't safe, because the implementation could be already using them for 
something else. Some replies on the reflector suggested the only reliable argument is one obtained from 
<tt>ios_base::xalloc()</tt>. Others pointed out that the iwords and pwords could be stored in sparse 
arrays, so that any value from <tt>INT_MIN</tt> to <tt>INT_MAX</tt> could be a valid key (which might 
require the implementation to use keys outside that range for its own entries in the arrays).
<p/>
If it's undefined we should add a <i>Requires</i> element to the spec. If invalid indices are supposed 
to cause a failure we need to define which indices are invalid (and ensure that's something the 
implementation can check), and specify that it causes a failure.
</p>

<p><i>[
2018-03-27 Moved to Tentatively Ready after 5 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li>
<p>Edit 30.5.3.5 <a href="https://wg21.link/ios.base.storage">[ios.base.storage]</a> as indicated:</p>
<blockquote>
<pre>
long&amp; iword(int idx);
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <tt>idx</tt> is a value obtained by a call to <tt>xalloc</tt>.</ins>
<p/>
-3- <i>Effects:</i> If <tt>iarray</tt> is a null pointer, [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
void*&amp; pword(int idx);
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <tt>idx</tt> is a value obtained by a call to <tt>xalloc</tt>.</ins>
<p/>
-5- <i>Effects:</i> If <tt>iarray</tt> is a null pointer, [&hellip;]
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3094" href="#3094">3094</a><sup><a href="https://cplusplus.github.io/LWG/issue3094">(i)</a></sup>. &sect;[time.duration.io]p4 makes surprising claims about encoding</h3>
<p><b>Section:</b> 23.17.5.10 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2018-04-02 <b>Last modified:</b> 2018-05-06</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>
[time.duration.io]p4 says:
</p>
<blockquote><p>
For streams where <tt>charT</tt> has an 8-bit representation, <tt>"&micro;s"</tt> should be encoded as UTF-8. Otherwise UTF-16 or 
UTF-32 is encouraged. The implementation may substitute other encodings, including <tt>"us"</tt>.
</p></blockquote>
<p>
This choice of encoding is not up to the <tt>&lt;chrono&gt;</tt> library to decide or encourage. The basic execution character 
set determines how a mu should be encoded in type <tt>char</tt>, for instance, and it would be truly bizarre to use a UTF-8 
encoding if that character set is, say, Latin-1 or EBCDIC.
<p/>
I suggest we strike at least the first two sentences of this paragraph, as the meaning of the prior wording is unambiguous 
without them and confusing with them, and they do not providing any normative requirements (although they do provide 
recommendations). The third sentence appears to have a normative impact, but it's hard to see how it's legitimate to call 
<tt>"us"</tt> an "encoding" of <tt>"&micro;s"</tt>; it's really just an alternative unit suffix. So how about replacing that 
paragraph with this:
</p>
<blockquote><p>
If <tt>Period::type</tt> is <tt>micro</tt>, but the character U+00B5 cannot be represented in the encoding used for 
<tt>charT</tt>, the unit suffix <tt>"us"</tt> is used instead of <tt>"&micro;s"</tt>.
</p></blockquote>
<p>
(This also removes the permission for an implementation to choose an arbitrary alternative "encoding", which seems undesirable.)
</p>

<p><i>[
2018-04-23 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<ol>
<li>
<p>Edit 23.17.5.10 <a href="https://wg21.link/time.duration.io">[time.duration.io]</a> as indicated:</p>
<blockquote>
<pre>
template&lt;class charT, class traits, class Rep, class Period&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const duration&lt;Rep, Period&gt;&amp; d);
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> [&hellip;]
<p/>
-2- <i>Effects:</i> [&hellip;]
<p/>
-3- The units suffix depends on the type <tt>Period::type</tt> as follows:
</p>
<ol style="list-style-type: none">
<li><p>[&hellip;]</p></li>
<li><p>(3.5) &mdash; Otherwise, if <tt>Period::type</tt> is <tt>micro</tt>, the suffix is <tt>"&micro;s"</tt> 
(<tt>"\u00b5\u0073"</tt>).</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(3.21) &mdash; Otherwise, the suffix is <tt>"[<i>num</i>/<i>den</i>]s"</tt>.</p></li>
</ol>
<p>
[&hellip;]
<p/>
-4- <del>For streams where <tt>charT</tt> has an 8-bit representation, <tt>"&micro;s"</tt> should be encoded as UTF-8. 
Otherwise UTF-16 or UTF-32 is encouraged. The implementation may substitute other encodings, including 
<tt>"us"</tt></del><ins>If <tt>Period::type</tt> is <tt>micro</tt>, but the character U+00B5 cannot be represented 
in the encoding used for <tt>charT</tt>, the unit suffix <tt>"us"</tt> is used instead of <tt>"&micro;s"</tt></ins>.
<p/>
-5- <i>Returns:</i> <tt>os</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="3100" href="#3100">3100</a><sup><a href="https://cplusplus.github.io/LWG/issue3100">(i)</a></sup>. Unnecessary and confusing "empty <tt>span</tt>" wording</h3>
<p><b>Section:</b> 26.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2018-04-12 <b>Last modified:</b> 2018-05-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#span.cons">active issues</a> in [span.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#span.cons">issues</a> in [span.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>span</tt> constructors have wording relics that mention an "empty <tt>span</tt>". It's unnecessary (the 
behavior is fully specified by the postconditions), but I left it there because I thought it was harmless. It was 
later pointed out to me that this is actually confusing. Talking about an "empty <tt>span</tt>" implies that there's just 
one such thing, but <tt>span</tt> permits <tt>empty()</tt> to be <tt>true</tt> while <tt>data()</tt> can vary 
(being null or non-null). (This behavior is very useful; consider how <tt>equal_range()</tt> behaves.)
<p/>
To avoid confusion, the "empty <tt>span</tt>" wording should simply be removed, leaving the constructor behavior unchanged. 
Editorially, there's also a missing paragraph number.
</p>

<p><i>[
2018-04-24 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<blockquote>
<ol>
<li>
<p>Edit 26.7.3.2 <a href="https://wg21.link/span.cons">[span.cons]</a> as indicated:</p>
<blockquote>
<pre>
constexpr span() noexcept;
</pre>
<blockquote>
<p>
<del>-1- <i>Effects:</i> Constructs an empty <tt>span</tt>.</del>
<p/>
-2- <i>Postconditions:</i> <tt>size() == 0 &amp;&amp; data() == nullptr</tt>.
<p/>
-3- <i>Remarks:</i> This constructor shall not participate in overload resolution unless <tt>Extent &lt;= 0</tt> is <tt>true</tt>.
</p>
</blockquote>
<pre>
constexpr span(pointer ptr, index_type count);
</pre>
<blockquote>
<p>
-4- <i>Requires:</i> <tt>[ptr, ptr + count)</tt> shall be a valid range. If <tt>extent</tt> is not equal to 
<tt>dynamic_extent</tt>, then <tt>count</tt> shall be equal to <tt>extent</tt>.
<p/>
-5- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the range <tt>[ptr, ptr + count)</tt>. <del>If 
<tt>count</tt> is <tt>0</tt> then an empty span is constructed.</del>
<p/>
-6- <i>Postconditions:</i> <tt>size() == count &amp;&amp; data() == ptr</tt>.
<p/>
<ins>-?-</ins> <i>Throws:</i> Nothing.
</p>
</blockquote>
<pre>
constexpr span(pointer first, pointer last);
</pre>
<blockquote>
<p>
-7- <i>Requires:</i> <tt>[first, last)</tt> shall be a valid range. If <tt>extent</tt> is not equal to 
<tt>dynamic_extent</tt>, then <tt>last - first</tt> shall be equal to <tt>extent</tt>.
<p/>
-8- <i>Effects:</i> Constructs a <tt>span</tt> that is a view over the range <tt>[first, last)</tt>. <del>If 
<tt>last - first == 0</tt> then an empty <tt>span</tt> is constructed.</del>
<p/>
-9- <i>Postconditions:</i> <tt>size() == last - first &amp;&amp; data() == first</tt>.
<p/>
-10- <i>Throws:</i> Nothing.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>





<hr>
<h3><a name="3102" href="#3102">3102</a><sup><a href="https://cplusplus.github.io/LWG/issue3102">(i)</a></sup>. Clarify <tt>span iterator</tt> and <tt>const_iterator</tt> behavior</h3>
<p><b>Section:</b> 26.7.3.1 <a href="https://wg21.link/span.overview">[span.overview]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2018-04-12 <b>Last modified:</b> 2018-05-06</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>
There are multiple issues with how span specifies its iterators:
</p>
<ul>
<li><p><tt>const_iterator</tt> isn't mentioned.</p></li>
<li><p>The relationship between <tt>iterator</tt> and <tt>const_iterator</tt> isn't specified. (<tt>span</tt> isn't 
a container, so it doesn't receive this automatically.)</p></li>
<li><p>The iterators should be specified to be constexpr.</p></li>
</ul>
<p>
By imitating 24.4.2.2 <a href="https://wg21.link/string.view.iterators">[string.view.iterators]</a>/3 "All requirements on container iterators ([container.requirements]) 
apply to <tt>basic_string_view::const_iterator</tt> as well.", we can specify that <tt>iterator</tt> is convertible to 
<tt>const_iterator</tt>.
</p>

<p><i>[
2018-04-23 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<blockquote>
<ol>
<li>
<p>Edit 26.7.3.1 <a href="https://wg21.link/span.overview">[span.overview]</a> as indicated:</p>
<blockquote>
<p>
-4- The iterator type<ins>s</ins> <del>for span is a random access iterator and a contiguous iterator</del><ins><tt>span::iterator</tt> 
and <tt>span::const_iterator</tt> are random access iterators (27.2.7 <a href="https://wg21.link/random.access.iterators">[random.access.iterators]</a>), contiguous iterators
(27.2.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>), and constexpr iterators (27.2.1 <a href="https://wg21.link/iterator.requirements.general">[iterator.requirements.general]</a>). 
All requirements on container iterators (26.2 <a href="https://wg21.link/container.requirements">[container.requirements]</a>) apply to <tt>span::iterator</tt> and 
<tt>span::const_iterator</tt> as well</ins>.
</p>
</blockquote>
</li>
</ol>
</blockquote>





<hr>
<h3><a name="3104" href="#3104">3104</a><sup><a href="https://cplusplus.github.io/LWG/issue3104">(i)</a></sup>. Fixing <tt>duration</tt> division</h3>
<p><b>Section:</b> 23.17.5.5 <a href="https://wg21.link/time.duration.nonmember">[time.duration.nonmember]</a> <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Johel Ernesto Guerrero Pe&ntilde;a <b>Opened:</b> 2018-04-17 <b>Last modified:</b> 2018-05-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#time.duration.nonmember">issues</a> in [time.duration.nonmember].</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>
[time.duration.nonmember]/1 states
</p>
<blockquote><p>
In the function descriptions that follow, <tt>CD</tt> represents the return type of the function.
</p></blockquote>
<p>
From what I could find, many definitions of <tt>CD</tt> in the paragraphs of [time.duration.nonmember] were lifted to 
[time.duration.nonmember]/1 as cited above. That works for all other paragraphs, but not for [time.duration.nonmember]/10, 
which the change rendered ill-formed:
</p>
<blockquote>
<pre>
template&lt;class Rep1, class Period1, class Rep2, class Period2&gt;
  constexpr common_type_t&lt;Rep1, Rep2&gt;
    operator/(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre>
<blockquote>
<i>Returns:</i> <tt>CD(lhs).count() / CD(rhs).count()</tt>.
</blockquote>
</blockquote>
<p>
In this case, we want <tt>CD</tt> to mean <tt>common_type_t&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;</tt>. 
That way, the division has the expected semantics of dividing two quantities of the same dimension.
</p>

<p><i>[
2018-04-24 Moved to Tentatively Ready after 6 positive votes on c++std-lib.
]</i></p>



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

<blockquote>
<ol>
<li>
<p>Edit 23.17.5.5 <a href="https://wg21.link/time.duration.nonmember">[time.duration.nonmember]</a> as indicated:</p>
<blockquote>
<p>
-1- In the function descriptions that follow, <ins>unless stated otherwise, let</ins> <tt>CD</tt> represent<del>s</del> 
the return type of the function.
<p/>
[&hellip;]
</p>
<pre>
template&lt;class Rep1, class Period1, class Rep2, class Period2&gt;
  constexpr common_type_t&lt;Rep1, Rep2&gt;
    operator/(const duration&lt;Rep1, Period1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<ins>Let <tt>CD</tt> be <tt>common_type_t&lt;duration&lt;Rep1, Period1&gt;, duration&lt;Rep2, Period2&gt;&gt;</tt>.</ins>
<p/>
-10- <i>Returns:</i> <tt>CD(lhs).count() / CD(rhs).count()</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>





</body>
</html>
