<!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 Oulu</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 Oulu</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0165R2</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2016-05-30 at 02:05:30 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="2181" href="#2181">2181.</a> Exceptions from <em>seed sequence</em> operations</h3>
<p><b>Section:</b> 26.6.1.2 [rand.req.seedseq], 26.6.3 [rand.eng], 26.6.4 [rand.adapt] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2012-08-18 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#rand.req.seedseq">issues</a> in [rand.req.seedseq].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
LWG issue <a href="lwg-defects.html#2180">2180</a> points out some deficiences in regard to the specification of the library-provided
type <tt>std::seed_seq</tt> regarding exceptions, but there is another specification problem 
in regard to general types satisfying the <em>seed sequence</em> constraints (named <tt>SSeq</tt>) as described in 
26.6.1.2 [rand.req.seedseq].
<p/>
26.6.3 [rand.eng] p3 and 26.6.4.1 [rand.adapt.general] p3 say upfront:
</p>
<blockquote><p>
Except where specified otherwise, no function described in this section 
26.6.3 [rand.eng]/26.6.4 [rand.adapt] throws an exception.
</p></blockquote>
<p>
This constraint causes problems, because the described templates in these sub-clauses depend on operations of 
<tt>SSeq::generate()</tt> which is a function template, that depends both on operations provided by the 
implementor of <tt>SSeq</tt> (e.g. of <tt>std::seed_seq</tt>), and those of the random access iterator type 
provided by the caller. With class template <tt>linear_congruential_engine</tt> we have just one example for a user 
of <tt>SSeq::generate()</tt> via:
</p>
<blockquote><pre>
template&lt;class Sseq&gt; 
linear_congruential_engine&lt;&gt;::linear_congruential_engine(Sseq&amp; q);

template&lt;class Sseq&gt; 
void linear_congruential_engine&lt;&gt;::seed(Sseq&amp; q);
</pre></blockquote>
<p>
None of these operations has an exclusion rule for exceptions.
<p/>
As described in <a href="lwg-defects.html#2180">2180</a> the wording for <tt>std::seed_seq</tt> should and can be fixed to ensure that 
operations of <tt>seed_seq::generate()</tt> won't throw except from operations of the provided iterator range, 
but there is no corresponding "safety belt" for user-provided <tt>SSeq</tt> types, since 26.6.1.2 [rand.req.seedseq]
does not impose no-throw requirements onto operations of <em>seed sequences</em>.
</p>

<ol style="list-style-type:upper-roman">

<li><p>
A quite radical step to fix this problem would be to impose general no-throw requirements on the expression
<tt>q.generate(rb,re)</tt> from Table 115, but this is not as simple as it looks initially, because this
function again depends on general types that are mutable random access iterators. Typically, we do not
impose no-throw requirements on iterator operations and this would restrict general seed sequences where
exceptions are not a problem. Furthermore, we do not impose comparable constraints for other expressions,
like that of the expression <tt>g()</tt> in Table 116 for good reasons, e.g. <tt>random_device::operator()</tt>
explicitly states when it throws exceptions.
</p></li>

<li><p>
A less radical variant of the previous suggestion would be to add a normative requirement on the expression
<tt>q.generate(rb,re)</tt> from Table 115 that says: "Throws nothing if operations of <tt>rb</tt> and <tt>re</tt> 
do not throw exceptions". Nevertheless we typically do not describe <em>conditional</em> Throws elements in proper
requirement sets elsewhere (Container requirements excluded, they just describe the containers from Clause 23)
and this may exclude resonable implementations of seed sequences that could throw exceptions under rare
situations. 
</p></li>

<li><p>
The iterator arguments provided to <tt>SSeq::generate()</tt> for operations in templates of 26.6.3 [rand.eng] and 
26.6.4 [rand.adapt] are under control of implementations, so we could impose stricter exceptions requirements
on <tt>SSeq::generate()</tt> for <tt>SSeq</tt> types that are used to instantiate member templates in 26.6.3 [rand.eng] 
and 26.6.4 [rand.adapt] solely.
</p></li>

<li><p>
We simply add extra wording to the introductive parts of 26.6.3 [rand.eng] and 26.6.4 [rand.adapt]
that specify that operations of the engine (adaptor) templates that depend on a template parameter <tt>SSeq</tt>
throw no exception unless <tt>SSeq::generate()</tt> throws an exception.
</p></li>
</ol>

<p>
Given these options I would suggest to apply the variant described in the fourth bullet.
<p/>
The proposed resolution attempts to reduce a lot of the redundancies of requirements in the introductory paragraphs of 
26.6.3 [rand.eng] and 26.6.4 [rand.adapt] by introducing a new intermediate sub-clause 
"Engine and engine adaptor class templates" following sub-clause 26.6.2 [rand.synopsis]. This approach also
solves the problem that currently 26.6.3 [rand.eng] also describes requirements that apply for
26.6.4 [rand.adapt] (Constrained templates involving the <tt>Sseq</tt> parameters).
</p>

<p><i>[2013-04-20, Bristol]</i></p>


<p>
Remove the first bullet point:
</p>
<blockquote><p>
?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.6.3 [rand.eng] and 26.6.4 [rand.adapt]. Phrases of the form "in those 
sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.6.3 [rand.eng] and 26.6.4 [rand.adapt]". 
</p></blockquote>
<p>
Replace "in those sub-clauses" with "in sub-clauses 26.6.3 [rand.eng] and 26.6.4 [rand.adapt]".
<p/>
Find another place for the wording. 
<p/>
Daniel: These are requirements on the implementation not on the types. I'm not comfortable in moving it to another place 
without double checking. 
<p/>
Improve the text (there are 4 "for"s): <em>for</em> copy constructors, <em>for</em> copy assignment operators, 
<em>for</em> streaming operators, and <em>for</em> equality and inequality operators are not shown in the synopses. 
<p/>
Move the information of this paragraph to the paragraphs it refers to: 
</p>
<blockquote><p>
"-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.6.1.4 [rand.req.eng], for adaptor operations that are not described in 26.6.1.5 [rand.req.adapt], or for 
operations where there is additional semantic information. In particular, declarations for copy constructors, for 
copy assignment operators, for streaming operators, and for equality and inequality operators are not shown in the synopses." 
</p></blockquote>
<p>
Alisdair: I prefer duplication here than consolidation/reference to these paragraphs. 
<p/>
The room showed weakly favjust or for duplication. 
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<ol>
<li><p>Add a new sub-clause titled "Engine and engine adaptor class templates" following sub-clause 
26.6.2 [rand.synopsis] (but at the same level) and add one further sub-clause "General" as
child of the new sub-clause as follows:
<p/>
<ins>Engine and engine adaptor class templates [rand.engadapt]</ins>
<p/>
<ins>General [rand.engadapt.general]</ins>
</p>
<blockquote><p>
<ins>-?- Throughout this sub-clause general requirements and conventions are described that apply to every class 
template specified in sub-clause 26.6.3 [rand.eng] and 26.6.4 [rand.adapt]. Phrases of the 
form "in those sub-clauses" shall be interpreted as equivalent to "in sub-clauses 26.6.3 [rand.eng] and 
26.6.4 [rand.adapt]".
</ins>
<p/>
<ins>-?- Except where specified otherwise, the complexity of each function specified in those sub-clauses is constant.</ins>
<p/>
<ins>-?- Except where specified otherwise, no function described in those sub-clauses throws an exception.</ins>
<p/>
<ins>-?- Every function described in those sub-clauses that has a function parameter <tt>q</tt> of type
<tt>SSeq&amp;</tt> for a template type parameter named <tt>SSeq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
<ins>-?- Descriptions are provided in those sub-clauses only for engine operations that are not described in 
26.6.1.4 [rand.req.eng], for adaptor operations that are not described in 26.6.1.5 [rand.req.adapt],
or for operations where there is additional semantic information. In particular, declarations for copy constructors,
for copy assignment operators, for streaming operators, and for equality and inequality operators
are not shown in the synopses.</ins>
<p/>
<ins>-?- Each template specified in those sub-clauses requires one or more relationships, involving the value(s) of
its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.</ins>
<p/>
<ins>-?- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in those 
sub-clauses:</ins>
</p>
<ul>
<li><p>
<ins>if the constructor</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; explicit X(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;</ins>
</p>
</li>

<li><p>
<ins>if the member function</ins>
</p>
<blockquote><pre>
<ins>template &lt;class Sseq&gt; void seed(Sseq&amp; q);</ins>
</pre></blockquote>
<p>
<ins>is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;</ins>
</p>
</li>
</ul>
<p>
<ins>The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.</ins>
</p>
</blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.6.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.6.3 [rand.eng] satisfies the 
requirements of a random number engine (26.6.1.4 [rand.req.eng]) type <ins>and the general implementation 
requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.3 [rand.eng] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.6.3 [rand.eng] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.6.3 [rand.eng] only for engine operations that are not 
described in 26.6.1.4 [rand.req.eng] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.6.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
<p/>
<del>-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.6.3 [rand.eng]) and in sub-clause 26.6.3 [rand.eng]: [&hellip;]</del>
</p></blockquote>

</li>

<li><p>Edit the contents of sub-clause 26.6.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section <del>26.6.3 [rand.eng]</del><ins>26.6.4 [rand.adapt]</ins> satisfies the 
requirements of a random number engine adaptor (26.6.1.5 [rand.req.adapt]) type <ins>and the general 
implementation requirements specified in sub-clause [rand.engadapt.general]</ins>.
<p/>
<del>-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.4 [rand.adapt] 
is constant.</del>
<p/>
<del>-3- Except where specified otherwise, no function described in this section 26.6.4 [rand.adapt] throws an exception.</del>
<p/>
<del>-4- Descriptions are provided in this section 26.6.4 [rand.adapt] only for engine operations that are not 
described in 26.6.1.5 [rand.req.adapt] [&hellip;]</del>
<p/>
<del>-5- Each template specified in this section 26.6.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. [&hellip;]</del>
</p></blockquote>

</li>

</ol>
</blockquote>

<p><i>[2014-02-09, Daniel provides alternative resolution]</i></p>


<p><i>[Lenexa 2015-05-07: Move to Ready]</i></p>

<p>LWG 2181 exceptions from seed sequence operations</p>
<p>STL: Daniel explained that I was confused. I said, oh, seed_seq says it can throw if the RanIt throws. Daniel says the RanIts are provided by the engine. Therefore if you give a seed_seq to an engine, it cannot throw, as implied by the current normative text. So what Daniel has in the PR is correct, if slightly unnecessary. It's okay to have explicitly non-overlapping Standardese even if overlapping would be okay.</p>
<p>Marshall: And this is a case where the std:: on seed_seq is a good thing.</p>
<p>STL: Meh.</p>
<p>STL: And that was my only concern with this PR. I like the latest PR much better than the previous.</p>
<p>Marshall: Yes. There's a drive-by fix for referencing the wrong section. Other than that, the two are the same.</p>
<p>STL: Alisdair wanted the repetition instead of centralization, and I agree.</p>
<p>Marshall: Any other opinions?</p>
<p>Jonathan: I'll buy it.</p>
<p>STL: For a dollar?</p>
<p>Hwrd: I'll buy that for a nickel.</p>
<p>Marshall: Any objections to Ready? I don't see a point in Immediate.</p>
<p>Jonathan: Absolutely agree.</p>
<p>Marshall: 7 for ready, 0 opposed, 0 abstain.</p>

<p><i>[2014-05-22, Daniel syncs with recent WP]</i></p>


<p><i>[2015-10-31, Daniel comments and simplifies suggested wording changes]</i></p>

<p>
Upon Walter Brown's suggestion the revised wording does not contain any wording changes that could be
considered as editorial. 
</p>

<p>
<strong>Previous resolution from Daniel [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Edit the contents of sub-clause 26.6.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 26.6.3 [rand.eng] satisfies the 
requirements of a random number engine (26.6.1.4 [rand.req.eng]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.3 [rand.eng] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.6.3 [rand.eng] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.6.3 [rand.eng] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.6.3 [rand.eng] only for engine operations that are not 
described in 26.6.1.4 [rand.req.eng] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and 
for</del> equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.6.3 [rand.eng] requires one or more relationships, 
involving the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is 
ill-formed if any such required relationship fails to hold.
<p/>
-6- For every random number engine and for every random number engine adaptor <tt>X</tt> defined in this subclause
(26.6.3 [rand.eng]) and in sub-clause 26.6.4 [rand.adapt]: 
</p>
<ul>
<li><p>
if the constructor
</p>
<blockquote><pre>
template &lt;class Sseq&gt; explicit X(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this constructor shall not
participate in overload resolution;
</p>
</li>
<li><p>
if the member function
</p>
<blockquote><pre>
template &lt;class Sseq&gt; void seed(Sseq&amp; q);
</pre></blockquote>
<p>
is called with a type <tt>Sseq</tt> that does not qualify as a seed sequence, then this function shall not
participate in overload resolution;
</p>
</li>
</ul>
<p>
The extent to which an implementation determines that a type cannot be a seed sequence is unspecified,
except that as a minimum a type shall not qualify as a seed sequence if it is implicitly convertible to
<tt>X::result_type</tt>.
</p>
</blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.6.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- Each type instantiated from a class template specified in this section 
<del>26.6.3 [rand.eng]</del><ins>26.6.4 [rand.adapt]</ins> satisfies the requirements of a 
random number engine adaptor (26.6.1.5 [rand.req.adapt]) type.
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.4 [rand.adapt] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.6.4 [rand.adapt] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.6.4 [rand.adapt] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
-4- Descriptions are provided in this section 26.6.4 [rand.adapt] only for adaptor operations that are not 
described in section 26.6.1.5 [rand.req.adapt] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
<p/>
-5- Each template specified in this section 26.6.4 [rand.adapt] requires one or more relationships, involving 
the value(s) of its non-type template parameter(s), to hold. A program instantiating any of these templates is ill-formed if
any such required relationship fails to hold.
</p></blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.6.8.1 [rand.dist.general] p2 as indicated: [<i>Drafting note</i>: These
editorial changes are just for consistency with those applied to 26.6.3 [rand.eng] and 
26.6.4.1 [rand.adapt.general] &mdash; <i>end drafting note</i>]</p>

<blockquote><p>
-2- Descriptions are provided in this section 26.6.8 [rand.dist] only for distribution operations that are not 
described in 26.6.1.6 [rand.req.dist] or for operations where there is additional semantic information. In particular, 
declarations for copy constructors, <del>for</del> copy assignment operators, <del>for</del> streaming operators, <del>and for</del> 
equality <ins>operators,</ins> and inequality operators are not shown in the synopses.
</p></blockquote>
</li>

</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4527.</p>

<ol>
<li><p>Edit the contents of sub-clause 26.6.3 [rand.eng] as indicated:</p>

<blockquote><p>
-1- [&hellip;]
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.3 [rand.eng] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.6.3 [rand.eng] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.6.3 [rand.eng] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</li>

<li><p>Edit the contents of sub-clause 26.6.4.1 [rand.adapt.general] as indicated:</p>

<blockquote><p>
-1- [&hellip;]
<p/>
-2- Except where specified otherwise, the complexity of each function specified in this section 26.6.4 [rand.adapt] 
is constant.
<p/>
-3- Except where specified otherwise, no function described in this section 26.6.4 [rand.adapt] throws an exception.
<p/>
<ins>-?- Every function described in this section 26.6.4 [rand.adapt] that has a function parameter <tt>q</tt> of 
type <tt>Sseq&amp;</tt> for a template type parameter named <tt>Sseq</tt> that is different from type <tt>std::seed_seq</tt> 
throws what and when the invocation of <tt>q.generate</tt> throws.</ins>
</p></blockquote>
</li>

</ol>





<hr>
<h3><a name="2309" href="#2309">2309.</a> <tt>mutex::lock()</tt> should not throw <tt>device_or_resource_busy</tt></h3>
<p><b>Section:</b> 30.4.1.2 [thread.mutex.requirements.mutex] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Detlef Vollmann <b>Opened:</b> 2013-09-27 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#thread.mutex.requirements.mutex">issues</a> in [thread.mutex.requirements.mutex].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
As discussed during the Chicago meeting in 
<a href="http://wiki.edg.com/twiki/bin/view/Wg21chicago2013/ThursdayMorningMinutes#LWG_2135_revisited">SG1</a>
the only reasonable reasons for throwing <tt>device_or_resource_busy</tt> seem to be:
</p>
<ul>
<li><p>
The thread currently already holds the mutex, the mutex is not recursive, and the implementation detects this.
In this case <tt>resource_deadlock_would_occur</tt> should be thrown.
</p></li>
<li><p>
Priority reasons. At least <tt>std::mutex</tt> (and possibly all standard mutex types)
should not be setup this way, otherwise we have real problems with <tt>condition_variable::wait()</tt>.
</p></li>
</ul>

<p><i>[2014-06-17 Rapperswil]</i></p>

<p>
Detlef provides wording
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
Handed over to SG1.
</p>

<p><i>[2015-05 Lenexa, SG1 response]</i></p>

<p>
We believe we were already done with it. Should be in SG1-OK status.
</p>

<p><i>[2015-10 pre-Kona]</i></p>

<p>
SG1 hands this over to LWG for wording review
</p>

<p><i>[2015-10 Kona]</i></p>

<p>
Geoffrey provides new wording.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>

<blockquote><p>
-13- <i>Error conditions</i>:
</p>
<ul>
<li><p><tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</p></li>
<li><p><tt>resource_deadlock_would_occur</tt> &mdash; if the implementation detects that a deadlock would occur.</p></li>
<li><p><del><tt>device_or_resource_busy</tt> &mdash; if the mutex is already locked and blocking is not possible.</del></p></li>
</ul>
</blockquote>
</li>
</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4527.</p>

<ol>
<li><p>Change 30.4.1.2 [thread.mutex.requirements.mutex] as indicated:</p>

<blockquote>
<p>
[&hellip;]
<p/>
-4- The error conditions for error codes, if any, reported by member functions of the mutex types shall be:
</p>
<ol style="list-style-type: none">
<li><p>(4.1) &mdash; <tt>resource_unavailable_try_again</tt> &mdash; if any native handle type manipulated is not available.</p></li>
<li><p>(4.2) &mdash; <tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</p></li>
<li><p><del>(4.3) &mdash; <tt>device_or_resource_busy</tt> &mdash; if any native handle type manipulated is already locked.</del></p></li>
</ol>
<p>
[&hellip;]
<p/>
-13- <i>Error conditions</i>:
</p>
<ol style="list-style-type: none">
<li><p>(13.1) &mdash; <tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</p></li>
<li><p>(13.2) &mdash; <tt>resource_deadlock_would_occur</tt> &mdash; if the implementation detects that a deadlock would occur.</p></li>
<li><p><del>(13.3) &mdash; <tt>device_or_resource_busy</tt> &mdash; if the mutex is already locked and blocking is not possible.</del></p></li>
</ol>
</blockquote>
</li>

<li><p>Change 30.4.1.4 [thread.sharedmutex.requirements] as indicated:</p>

<blockquote>
<p>
[&hellip;]
<p/>
-10- <i>Error conditions</i>:
</p>
<ol style="list-style-type: none">
<li><p>(10.1) &mdash; <tt>operation_not_permitted</tt> &mdash; if the thread does not have the privilege to perform the operation.</p></li>
<li><p>(10.2) &mdash; <tt>resource_deadlock_would_occur</tt> &mdash; if the implementation detects that a deadlock would occur.</p></li>
<li><p><del>(10.3) &mdash; <tt>device_or_resource_busy</tt> &mdash; if the mutex is already locked and blocking is not possible.</del></p></li>
</ol>
<p>
[&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2310" href="#2310">2310.</a> Public <em>exposition only</em> member in <tt>std::array</tt></h3>
<p><b>Section:</b> 23.3.7.1 [array.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-09-30 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>4
</p>
<p><b>View all other</b> <a href="lwg-index.html#array.overview">issues</a> in [array.overview].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
23.3.7.1 [array.overview] shows <tt>std::array</tt> with an "exposition only" data member, <tt>elems</tt>.
<p/>
The wording in 17.5.2.3 [objects.within.classes] that defines how
"exposition only" is used says it applies to private members, but
<tt>std::array::elems</tt> (or its equivalent) must be public in order for
<tt>std::array</tt> to be an aggregate.
<p/>
If the intention is that <tt>std::array::elems</tt> places requirements on the
implementation to provide "equivalent external behavior" to a public
array member, then 17.5.2.3 [objects.within.classes] needs to cover public
members too, or some other form should be used in 23.3.7.1 [array.overview].
</p>

<p><i>[Urbana 2014-11-07: Move to Open]</i></p>

<p><i>[Kona 2015-10: Link to <a href="lwg-active.html#2516">2516</a>]</i></p>

<p><i>[2015-11-14, Geoffrey Romer provides wording]</i></p>


<p><i>[2016-02-04, Tim Song improves the P/R]</i></p>

<p>
Instead of the build-in address-operator, <tt>std::addressof</tt> should be used.
</p>

<p><i>[2016-03 Jacksonville]</i></p>

Move to Ready.


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4567.</p>

<ol>
<li><p>Edit 23.3.7.1 [array.overview] as indicated</p>

<blockquote>
<p>
[&hellip;]
<p/>
-3- An array [&hellip;]
</p>
<blockquote><pre>
namespace std {
  template &lt;class T, size_t N&gt;
  struct array {
    [&hellip;]
    <del>T elems[N]; <i>// exposition only</i></del>
    [&hellip;]
  };
}
</pre></blockquote>
<p>
<del>-4- [<i>Note</i>: The member variable <tt>elems</tt> is shown for exposition only, to emphasize that array is a class aggregate.
The name <tt>elems</tt> is not part of array's interface. &mdash; <i>end note</i>]</del>
</p>
</blockquote>
</li>

<li><p>Edit 23.3.7.5 [array.data] as follows:</p>

<blockquote>
<pre>
T* data() noexcept;
const T* data() const noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: <del><tt>elems</tt></del><ins>A pointer such that <tt>[data(), data() + size())</tt> is a valid range, 
and <tt>data() == addressof(front())</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2328" href="#2328">2328.</a> Rvalue stream extraction should use perfect forwarding</h3>
<p><b>Section:</b> 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2013-09-21 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#istream.rvalue">active issues</a> in [istream.rvalue].</p>
<p><b>View all other</b> <a href="lwg-index.html#istream.rvalue">issues</a> in [istream.rvalue].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
27.7.2.6 [istream.rvalue] declares <tt>operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp; x)</tt>.  
However, 27.7.2.2.3 [istream::extractors]/7 declares <tt>operator&gt;&gt;(basic_istream&lt;charT,traits&gt;&amp; in, charT* s)</tt>, 
plus additional overloads for <tt>unsigned char*</tt> and <tt>signed char*</tt>. This means that 
"<tt>return_rvalue_istream() &gt;&gt; &amp;arr[0]</tt>" won't compile, because <tt>T&amp;</tt> won't bind to the rvalue 
<tt>&amp;arr[0]</tt>.
</p>

<p><i>[2014-02-12 Issaquah : recategorize as P3]</i></p>


<p>
Jonathan Wakely: Bill was certain the change is right, I think so with less certainty
</p>

<p>
Jeffrey Yaskin: I think he's right, hate that we need this
</p>

<p>
Jonathan Wakely: is this the security issue Jeffrey raised on lib reflector?
</p>

<p>
Move to P3
</p>

<p><i>[2015-05-06 Lenexa: Move to Review]</i></p>


<p>WEB, MC: Proposed wording changes one signature (in two places) to take a forwarding reference.</p>
<p>TK: Should be consistent with an istream rvalue?</p>
<p>MC: This is the case where you pass the stream by rvalue reference.</p>
<p>RP: I would try it before standardizing.</p>
<p>TK: Does it break anything?</p>
<p>RP, TK: It will take all arguments, will be an exact match for everything.</p>
<p>RS, TK: This adapts streaming into an rvalue stream to make it act like streaming into an lvalue stream.</p>
<p>RS: Should this really return the stream by lvalue reference instead of by rvalue reference? &rArr; new LWG issue.</p>
<p>RP: Security issue?</p>
<p>MC: No. That's <tt>istream &gt;&gt; char*</tt>, C++ version of <tt>gets()</tt>. Remove it, as we did for 
<tt>gets()</tt>? &rArr; new LWG issue.</p>
<p>RS: Proposed resolution looks correct to me.</p>
<p>MC: Makes me (and Jonathan Wakely) feel uneasy.</p>
<p>Move to Review, consensus.</p>

<p><i>[2016-01-15, Daniel comments and suggests improved wording]</i></p>

<p>
It has been pointed out by Tim Song, that the initial P/R (deleting the <i>Returns</i> paragraph and making the <i>Effects</i> 
"equivalent to <tt>return is &gt;&gt; /* stuff */;</tt>") breaks cases where the applicable <tt>operator&gt;&gt;</tt> doesn't 
return a type that is convertible to a reference to the stream:
</p>
<blockquote><pre>
struct A{};
void operator&gt;&gt;(std::istream&amp;, A&amp;){ }

void f() {
  A a;
  std::istringstream() &gt;&gt; a; // was OK, now error
}
</pre></blockquote>
<p>
This seems like an unintended wording artifact of the "Equivalent to" Phrase Of Power
and could be easily fixed by changing the second part of the P/R slightly as follows:
</p>
<blockquote><pre>
template &lt;class charT, class traits, class T&gt;
  basic_istream&lt;charT, traits&gt;&amp;
  operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> <ins>Equivalent to:</ins><del><tt>is &gt;&gt;x</tt></del>
</p>
<blockquote><pre>
<ins>is &gt;&gt; std::forward&lt;T&gt;(x);
return is;</ins>
</pre></blockquote>
<p>
<del>-2- <i>Returns:</i> <tt>is</tt></del>
</p>
</blockquote></blockquote>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4567.</p>

<ol>
<li><p>Edit 27.7.1 [iostream.format.overview], header <tt>&lt;istream&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  template &lt;class charT, class traits, class T&gt;
    basic_istream&lt;charT, traits&gt;&amp;
    operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
}
</pre></blockquote>
</li>

<li><p>Edit 27.7.2.6 [istream.rvalue] as indicated:</p>

<blockquote><pre>
template &lt;class charT, class traits, class T&gt;
  basic_istream&lt;charT, traits&gt;&amp;
  operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> <ins>Equivalent to <tt>return </tt></ins><tt>is &gt;&gt;<del>x</del> <ins>std::forward&lt;T&gt;(x)</ins></tt>
<p/>
<del>-2- <i>Returns:</i> <tt>is</tt></del>
</p>
</blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-03 Jacksonville: Move to Ready]</i></p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4567.</p>

<ol>
<li><p>Edit 27.7.1 [iostream.format.overview], header <tt>&lt;istream&gt;</tt> synopsis, as indicated:</p>

<blockquote><pre>
namespace std {
  [&hellip;]
  template &lt;class charT, class traits, class T&gt;
    basic_istream&lt;charT, traits&gt;&amp;
    operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
}
</pre></blockquote>
</li>

<li><p>Edit 27.7.2.6 [istream.rvalue] as indicated:</p>

<blockquote><pre>
template &lt;class charT, class traits, class T&gt;
  basic_istream&lt;charT, traits&gt;&amp;
  operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp;&amp; is, T&amp;<ins>&amp;</ins> x);
</pre><blockquote>
<p>
-1- <i>Effects:</i> <ins>Equivalent to:</ins><del><tt>is &gt;&gt;x</tt></del>
</p>
<blockquote><pre>
<ins>is &gt;&gt; std::forward&lt;T&gt;(x);
return is;</ins>
</pre></blockquote>
<p>
<del>-2- <i>Returns:</i> <tt>is</tt></del>
</p>
</blockquote></blockquote>

</li>
</ol>





<hr>
<h3><a name="2393" href="#2393">2393.</a> <tt>std::function</tt>'s <em>Callable</em> definition is broken</h3>
<p><b>Section:</b> 20.12.12.2 [func.wrap.func] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-06-03 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#func.wrap.func">active issues</a> in [func.wrap.func].</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func">issues</a> in [func.wrap.func].</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 existing definition of <tt>std::function</tt>'s <em>Callable</em> requirements provided in 20.12.12.2 [func.wrap.func]
p2,
</p>
<blockquote><p>
A callable object <tt>f</tt> of type <tt>F</tt> is <em>Callable</em> for argument types <tt>ArgTypes</tt> and return type 
<tt>R</tt> if the expression <tt><i>INVOKE</i>(f, declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand 
(Clause 5), is well formed (20.9.2).
</p></blockquote>
<p>
is defective in several aspects:
</p>
<ol style="list-style-type:upper-roman">
<li><p>The wording can be read to be defined in terms of callable objects, not of callable types.</p>
</li>
<li><p>Contrary to that, 20.12.12.2.5 [func.wrap.func.targ] p2 speaks of "<tt>T</tt> shall be a type that is <em>Callable</em> 
(20.9.11.2) for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>."</p>
</li>
<li><p>
The required value category of the callable object during the call expression (lvalue or rvalue) strongly depends on
an interpretation of the expression <tt>f</tt> and therefore needs to be specified unambiguously.
</p></li>
</ol>
<p>
The intention of original <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1402.html">proposal</a> 
(see IIIa. Relaxation of target requirements) was to refer to both types and values ("we say that the function object <tt>f</tt> 
(and its type <tt>F</tt>) is <em>Callable</em> [&hellip;]"), but that mental model is not really deducible from the
existing wording. An improved type-dependence wording would also make the sfinae-conditions specified in 20.12.12.2.1 [func.wrap.func.con] 
p8 and p21 ("[&hellip;] shall not participate in overload resolution unless <tt>f</tt> is Callable (20.9.11.2)
for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.") easier to interpret.
<p/>
My understanding always had been (see e.g. Howard's code example in the 2009-05-01 comment in LWG <a href="lwg-defects.html#815">815</a>), that 
<tt>std::function</tt> invokes the call operator of its target via an <b>lvalue</b>. The required value-category is relevant, 
because it allows to reflect upon whether an callable object such as
</p>
<blockquote><pre>
struct RVF 
{
  void operator()() const &amp;&amp; {}
};
</pre></blockquote>
<p>
would be a feasible target object for <tt>std::function&lt;void()&gt;</tt> or not.
<p/>
Clarifying the current <em>Callable</em> definition seems also wise to make a future transition to language-based concepts
easier. A local fix of the current wording is simple to achieve, e.g. by rewriting it as follows:
</p>
<blockquote><p>
A callable <del>object <tt>f</tt> of</del> type <ins>(20.12.1 [func.def])</ins> <tt>F</tt> is <em>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
<p>
It seems appealing to move such a general <em>Callable</em> definition to a more "fundamental" place (e.g. as another
paragraph of 20.12.1 [func.def]), but the question arises, whether such a more general concept should impose
the requirement that the call expression is invoked on an <b>lvalue</b> of the callable object &mdash; such a
special condition would also conflict with the more general definition of the <tt>result_of</tt> trait, which
is defined for either lvalues or rvalues of the callable type <tt>Fn</tt>. In this context I would like to point out that
"<em>Lvalue-Callable</em>" is not the one and only <em>Callable</em> requirement in the library. Counter examples are
<tt>std::thread</tt>, <tt>call_once</tt>, or <tt>async</tt>, which depend on "<em>Rvalue-Callable</em>", because they 
all act on functor rvalues, see e.g. 30.3.1.2 [thread.thread.constr]:
</p>
<blockquote><p>
[&hellip;] The new thread of execution executes <tt><i>INVOKE</i>(<i>DECAY_COPY</i>(std::forward&lt;F&gt;(f)), 
<i>DECAY_COPY</i>(std::forward&lt;Args&gt;(args))...)</tt> [&hellip;]
</p></blockquote>
<p>
For every callable object <tt>F</tt>, the result of <tt><i>DECAY_COPY</i></tt> is an rvalue. These implied rvalue function calls are 
no artifacts, but had been deliberately voted for by a Committee decision (see LWG <a href="lwg-defects.html#2021">2021</a>, 2011-06-13 comment) 
and existing implementations respect these constraints correctly. Just to give an example,
</p>
<blockquote><pre>
#include &lt;thread&gt;

struct LVF 
{
  void operator()() &amp; {}
};

int main()
{
  LVF lf;
  std::thread t(lf);
  t.join();
}
</pre></blockquote>
<p>
is supposed to be rejected.
<p/>
The below presented wording changes are suggested to be minimal (still local to <tt>std::function</tt>), but the used approach
would simplify a future (second) conceptualization or any further generalization of <em>Callable</em> requirements of the Library.
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
Related to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4348.html">N4348</a>. Don't touch with a barge pole. 
</p>

<p><i>[2015-09 Telecom]</i></p>

<p>
N4348 not going anywhere, can now touch with or without barge poles<br/>
Ville: where is Lvalue-Callable defined?<br/>
Jonathan: this is the definition. It's replacing Callable with a new term and defining that. Understand why it's needed, hate the change.<br/>
Geoff: punt to an LWG discussion in Kona<br/>
</p>

<p><i>[2015-10 Kona]</i></p>

<p>
STL: I like this in general. But we also have an opportunity here to add a precondition. By adding static assertions, 
we can make implementations better. Accept the PR but reinstate the requirement. 
<p/>
MC: Status Review, to be moved to TR at the next telecon.
</p>

<p><i>[2015-10-28 Daniel comments and provides alternative wording]</i></p>

<p>
The wording has been changed as requested by the Kona result. But I would like to provide the following counter-argument for this
changed resolution: Currently the following program is accepted by three popular Standard libraries, Visual Studio 2015, 
gcc 6 libstdc++, and clang 3.8.0 libc++:
</p>
<blockquote><pre>
#include &lt;functional&gt;
#include &lt;iostream&gt;
#include &lt;typeinfo&gt;
#include "boost/function.hpp"

void foo(int) {}

int main() {
  std::function&lt;void(int)&gt; f(foo);
  std::cout &lt;&lt; f.target&lt;double&gt;() &lt;&lt; std::endl;
  boost::function&lt;void(int)&gt; f2(foo);
  std::cout &lt;&lt; f2.target&lt;double&gt;() &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
and outputs the implementation-specific result for <b>two null pointer</b> values.
<p/>
Albeit this code is not conforming, it is probable that similar code exists in the wild. The current
<a href="http://www.boost.org/doc/libs/1_59_0/doc/html/boost/function_base.html">boost documentation</a>
does not indicate <em>any</em> precondition for calling the <tt>target</tt> function, so it is natural
that programmers would expect similar specification and behaviour.
<p/>
Standardizing the suggested change requires a change of all implementations and I don't see any advantage
for the user. With that change previously working code could now cause instantiation errors, I don't see how 
this could be considered as an improvement of the status quo. The result value of <tt>target</tt> is 
always a pointer, so a null-check by the user code is already required, therefore I really see no reason 
what kind of problem could result out of the current implementation behaviour, since the implementation 
never is required to perform a C cast to some funny type.
</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N3936.</p>

<ol>
<li><p>Change 20.12.12.2 [func.wrap.func] p2 as indicated:</p>

<blockquote><p>
-2- A callable <del>object <tt>f</tt> of</del> type <ins>(20.12.1 [func.def])</ins> <tt>F</tt> is <em><ins>Lvalue-</ins>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
</li>

<li><p>Change 20.12.12.2.1 [func.wrap.func.con] p8+p21 as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt><del>f</del><ins>F</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt><del>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</del><ins>decay_t&lt;F&gt;</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>

</blockquote>
</li>

<li><p>Change 20.12.12.2.5 [func.wrap.func.targ] p2 as indicated: [<i>Editorial comment</i>: Instead of adapting the preconditions
for the naming change I recommend to strike it completely, because the <tt>target()</tt> functions do not depend on it; the
corresponding wording exists since its <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2004/n1667.pdf">initial proposal</a>
and it seems without any advantage to me. Assume that some template argument <tt>T</tt> is provided, which does <em>not</em>
satisfy the requirements: The effect will be that the result is a null pointer value, but that case can happen in other (valid) situations
as well. &mdash; <i>end comment</i>]</p>

<blockquote><pre>
template&lt;class T&gt; T* target() noexcept;
template&lt;class T&gt; const T* target() const noexcept;
</pre>
<blockquote>
<p>
<del>-2- <i>Requires</i>: <tt>T</tt> shall be a type that is <tt>Callable</tt> (20.9.11.2) for parameter types 
<tt>ArgTypes</tt> and return type <tt>R</tt>.</del>
<p/>
-3- <i>Returns</i>: If <tt>target_type() == typeid(T)</tt> a pointer to the stored function target; otherwise a null
pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>GR explains the current short-comings. There's no concept in the standard that expresses rvalue member function qualification, and so, e.g. std::function cannot be forbidden from wrapping such functions. TK: Although it wouldn't currently compile.</p>
<p>GR: Implementations won't change as part of this. We're just clearing up the wording.</p>
<p>STL: I like this in general. But we also have an opportunity here to add a precondition. By adding static assertions, we can make implementations better. Accept the PR but reinstate the requirement.</p>
<p>JW: I hate the word "Lvalue-Callable". I don't have a better suggestion, but it'd be terrible to teach. AM: I like the term. I don't like that we need it, but I like it. AM wants the naming not to get in the way with future naming. MC: We'll review it.</p>
<p>TK: Why don't we also add Rvalue-Callable? STL: Because nobody consumes it.</p>
<p>Discussion whether "tentatively ready" or "review". The latter would require one more meeting. EF: We already have implementation convergence. MC: I worry about a two-meeting delay. WEB: All that being said, I'd be slightly more confident with a review since we'll have new wording, but I wouldn't object. MC: We can look at it in a telecon and move it.</p>
<p>STL reads out email to Daniel.</p>
<p>Status Review, to be moved to TR at the next telecon.</p>

<p><i>[2016-01-31, Daniel comments and suggests less controversive resolution]</i></p>

<p>
It seems that specifically the wording changes for 20.12.12.2.5 [func.wrap.func.targ] p2 prevent this issue
from making make progress. Therefore the separate issue LWG <a href="lwg-active.html#2591">2591</a> has been created, that focuses
solely on this aspect. Furtheron the current P/R of this issue has been adjusted to the minimal possible one,
where the term "Callable" has been replaced by the new term "Lvalue-Callable".
</p>

<p>
<strong>Previous resolution II [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>This wording is relative to N4527.</p>

<ol>
<li><p>Change 20.12.12.2 [func.wrap.func] p2 as indicated:</p>

<blockquote><p>
-2- A callable <del>object <tt>f</tt> of</del> type <ins>(20.12.1 [func.def])</ins> <tt>F</tt> is <em><ins>Lvalue-</ins>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
</li>

<li><p>Change 20.12.12.2.1 [func.wrap.func.con] p8+p21 as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt><del>f</del><ins>F</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt><del>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</del><ins>decay_t&lt;F&gt;</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.9.11.2) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>

</blockquote>
</li>

<li><p>Change 20.12.12.2.5 [func.wrap.func.targ] p2 as indicated:</p>

<blockquote><pre>
template&lt;class T&gt; T* target() noexcept;
template&lt;class T&gt; const T* target() const noexcept;
</pre>
<blockquote>
<p>
-2- <ins><i>Remarks</i>: If <tt>T</tt> is a type that is not <tt>Lvalue-Callable</tt> (20.9.11.2) for parameter types 
<tt>ArgTypes</tt> and return type <tt>R</tt>, the program is ill-formed</ins><del><i>Requires</i>: <tt>T</tt> shall be a type that is <tt>Callable</tt> (20.9.11.2) for parameter types 
<tt>ArgTypes</tt> and return type <tt>R</tt></del>.
<p/>
-3- <i>Returns</i>: If <tt>target_type() == typeid(T)</tt> a pointer to the stored function target; otherwise a null
pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-03 Jacksonville]</i></p>

Move to Ready.


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4567.</p>

<ol>
<li><p>Change 20.12.12.2 [func.wrap.func] p2 as indicated:</p>

<blockquote><p>
-2- A callable <del>object <tt>f</tt> of</del> type <ins>(20.12.1 [func.def])</ins> <tt>F</tt> is <em><ins>Lvalue-</ins>Callable</em> 
for argument types <tt>ArgTypes</tt> and return type <tt>R</tt> if the expression <tt><i>INVOKE</i>(<del>f</del><ins>declval&lt;F&amp;&gt;()</ins>, 
declval&lt;ArgTypes&gt;()..., R)</tt>, considered as an unevaluated operand (Clause 5), is well formed (20.9.2).
</p></blockquote>
</li>

<li><p>Change 20.12.12.2.1 [func.wrap.func.con] p8+p21 as indicated:</p>

<blockquote>
<pre>
template&lt;class F&gt; function(F f);
template &lt;class F, class A&gt; function(allocator_arg_t, const A&amp; a, F f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-8- <i>Remarks</i>: These constructors shall not participate in overload resolution unless <tt><del>f</del><ins>F</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.12.12.2 [func.wrap.func]) for argument types <tt>ArgTypes...</tt> and return type <tt>R</tt>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-21- <i>Remarks</i>: This assignment operator shall not participate in overload resolution unless 
<tt><del>declval&lt;typename decay&lt;F&gt;::type&amp;&gt;()</del><ins>decay_t&lt;F&gt;</ins></tt> is 
<tt><ins>Lvalue-</ins>Callable</tt> (20.12.12.2 [func.wrap.func]) for argument types <tt>ArgTypes...</tt> and 
return type <tt>R</tt>.
</p>
</blockquote>

</blockquote>
</li>

<li><p>Change 20.12.12.2.5 [func.wrap.func.targ] p2 as indicated:</p>

<blockquote><pre>
template&lt;class T&gt; T* target() noexcept;
template&lt;class T&gt; const T* target() const noexcept;
</pre>
<blockquote>
<p>
-2- <i>Requires</i>: <tt>T</tt> shall be a type that is <tt><ins>Lvalue-</ins>Callable</tt> (20.12.12.2 [func.wrap.func]) 
for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>.
<p/>
-3- <i>Returns</i>: If <tt>target_type() == typeid(T)</tt> a pointer to the stored function target; otherwise a null
pointer.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2426" href="#2426">2426.</a> Issue about <tt>compare_exchange</tt></h3>
<p><b>Section:</b> 29.6.5 [atomics.types.operations.req] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Hans Boehm <b>Opened:</b> 2014-08-25 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.operations.req">active issues</a> in [atomics.types.operations.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.operations.req">issues</a> in [atomics.types.operations.req].</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 standard is either ambiguous or misleading about the nature of accesses through the <tt>expected</tt> argument 
to the <tt>compare_exchange_*</tt> functions in 29.6.5 [atomics.types.operations.req]p21.
<p/>
It is unclear whether the access to <tt>expected</tt> is itself atomic (intent clearly no) and exactly when the implementation 
is allowed to read or write it. These affect the correctness of reasonable code.
<p/>
Herb Sutter, summarizing a complaint from Duncan Forster wrote:
</p>
<blockquote class="note">
<p>
Thanks Duncan,
<p/>
I think we have a bug in the standardese wording and the implementations are
legal, but let's check with the designers of the feature.
<p/>
Let me try to summarize the issue as I understand it:
</p>
<ol>
<li><p>
What I think was intended: Lawrence, I believe you championed having
<tt>compare_exchange_*</tt> take the <tt>expected</tt> value by reference, and update
<tt>expected</tt> on failure to expose the old value, but this was only for convenience
to simplify the calling loops which would otherwise always have to write an
extra "reload" line of code. Lawrence, did I summarize your intent correctly?
</p></li>
<li><p>
What I think Duncan is trying to do: However, it turns out that, now that
<tt>expected</tt> is an lvalue, it has misled(?) Duncan into trying to use the success of
<tt>compare_exchange_*</tt> to hand off ownership <em>of <tt>expected</tt> itself</em> to another
thread. For that to be safe, if the <tt>compare_exchange_*</tt> succeeds then the
thread that performed it must no longer read or write from <tt>expected</tt> else his
technique contains a race. Duncan, did I summarize your usage correctly? Is
that the only use that is broken?
</p></li>
<li><p>
What the standard says: I can see why Duncan thinks the standard supports
his use, but I don't think this was intended (I don't remember this being
discussed but I may have been away for that part) and unless you tell me this
was intended I think it's a defect in the standard. From 29.6.5 [atomics.types.operations.req]/21:
</p>
<blockquote><p>
-21- <i>Effects</i>: Atomically, compares the contents of the memory pointed to by
<tt>object</tt> or by <tt>this</tt> for equality with that in <tt>expected</tt>, and if true, replaces the
contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt>, and
if false, updates the contents of the memory in <tt>expected</tt> with the contents of
the memory pointed to by <tt>object</tt> or by <tt>this</tt>. [&hellip;]
</p></blockquote>
<p>
I think we have a wording defect here in any case, because the "atomically"
should not apply to the entire sentence &mdash; I'm pretty sure we never intended the
atomicity to cover the write to <tt>expected</tt>.
<p/>
As a case in point, borrowing from Duncan's mail below, I think the following
implementation is intended to be legal:
</p>
<blockquote><pre>
inline int _Compare_exchange_seq_cst_4(volatile _Uint4_t *_Tgt, _Uint4_t *_Exp, _Uint4_t _Value)
{ /* compare and exchange values atomically with
     sequentially consistent memory order */
  int _Res;
  _Uint4_t _Prev = _InterlockedCompareExchange((volatile long *)_Tgt, _Value, *_Exp);
  <span style="color:#C80000">if (_Prev == *_Exp) //!!!!! Note the unconditional read from *_Exp here</span>
    _Res = 1;
  else
  { /* copy old value */
    _Res = 0;
    *_Exp = _Prev;
  }
  return (_Res);
}
</pre></blockquote>
<p>
I think this implementation is intended to be valid &mdash; I think the only code that
could be broken with the "!!!!!" read of <tt>*_Exp</tt> is Duncan's use of treating
<tt>a.compare_exchange_*(expected, desired) == true</tt> as implying <tt>expected</tt> got
handed off, because then another thread could validly be using <tt>*_Exp</tt> &mdash; but we
never intended this use, right?
</p>
</li>
</ol>
</blockquote>
<p>
In a different thread Richard Smith wrote about the same problem:
</p>
<blockquote class="note">
<p>
The <tt>atomic_compare_exchange</tt> functions are described as follows:
</p>
<blockquote><p>
"Atomically, compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> 
for equality with that in <tt>expected</tt>, and if true, replaces the contents of the memory pointed to 
by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt>, and if false, updates the contents 
of the memory in <tt>expected</tt> with the contents of the memory pointed to by <tt>object</tt> or by 
<tt>this</tt>. Further, if the comparison is true, memory is affected according to the value of <tt>success</tt>, 
and if the comparison is false, memory is affected according to the value of <tt>failure</tt>."
</p></blockquote>
<p>
I think this is less clear than it could be about the effects of these operations on <tt>*expected</tt> in the failure case:
</p>
<ol>
<li><p>We have "Atomically, compares [&hellip;] and updates the contents of the memory in <tt>expected</tt> [&hellip;]". 
The update to the memory in <tt>expected</tt> is clearly not atomic, and yet this wording parallels the success case, 
in which the memory update is atomic.
</p></li>
<li><p>The wording suggests that memory (including <tt>*expected</tt>) is affected according to the value of <tt>failure</tt>. 
In particular, the failure order could be <tt>memory_order_seq_cst</tt>, which might lead someone to incorrectly think they'd 
published the value of <tt>*expected</tt>.</p></li>
</ol>
<p>
I think this can be clarified with no change in meaning by reordering the wording a little:
</p>
<blockquote><p>
"Atomically, compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> for equality with that in 
<tt>expected</tt>, and if true, replaces the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> with 
that in <tt>desired</tt><del>, and if</del><ins>. If the comparison is true, memory is affected according to the value of 
<tt>success</tt>, and if the comparison is false, memory is affected according to the value of <tt>failure</tt>. Further, 
if the comparison is</ins> false, <del>updates</del><ins>replaces</ins> the contents of the memory in <tt>expected</tt> with 
the <del>contents of</del><ins>value that was atomically read from</ins> the memory pointed to by <tt>object</tt> or by 
<tt>this</tt>. <del>Further, if the comparison is true, memory is affected according to the value of <tt>success</tt>, and 
if the comparison is false, memory is affected according to the value of <tt>failure</tt>.</del>"
</p></blockquote>
</blockquote>
<p>
Jens Maurer add:
</p>
<blockquote class="note">
<p>
I believe this is an improvement.
<p/>
I like to see the following additional improvements:
</p>
<ul>
<li><p>
"contents of the memory" is strange phrasing, which doesn't say how large the
memory block is. Do we compare the values or the value representation of the lvalue
<tt>*object</tt> (or <tt>*this</tt>)?
</p></li>
<li><p>
29.3 [atomics.order] defines memory order based on the "affected memory location". It would be
better to say something like "If the comparison is true, the memory synchronization order for the 
affected memory location <tt>*object</tt> is [&hellip;]"
</p></li>
</ul>
</blockquote>
<p>
There was also a discussion thread involving Herb Sutter, Hans Boehm, and Lawrence Crowl, resulting in proposed 
wording along the lines of:
</p>
<blockquote class="note">
<blockquote>
<p>
-21- <i>Effects</i>: Atomically with respect to <tt>expected</tt> and the memory pointed
to by <tt>object</tt> or by <tt>this</tt>, compares the contents of the memory pointed
to by <tt>object</tt> or by <tt>this</tt> for equality with that in <tt>expected</tt>, and if and
only if true, replaces the contents of the memory pointed to by <tt>object</tt>
or by <tt>this</tt> with that in desired, and if and only if false, updates the
contents of the memory in expected with the contents of the memory pointed to by 
<tt>object</tt> or by <tt>this</tt>.
</p>
</blockquote>
<p>
At the end of paragraph 23, perhaps add
</p>
<blockquote>
<p>
[<i>Example</i>: Because the <tt>expected</tt> value is updated only on failure,
code releasing the memory containing the <tt>expected</tt> value on success
will work. E.g. list head insertion will act atomically and not
have a data race in the following code.
</p>
<blockquote><pre>
do {
  p->next = head; // make new list node point to the current head
} while(!head.compare_exchange_weak(p->next, p)); // try to insert
</pre></blockquote>
<p>
&mdash; <i>end example</i>]
</p>
</blockquote>
</blockquote>
<p>
Hans objected that this still gives the misimpression that the update to <tt>expected</tt> is atomic.
</p>

<p><i>[2014-11 Urbana]</i></p>

<p>
Proposed resolution was added after Redmond.
</p>
<p>
Recommendations from SG1:
</p>
<ol>
<li>Change wording to <del>if true</del><ins>if and only if true</ins>, and change <del>if false</del><ins>if and only if false</ins>.</li>
<li>If they want to add "respect to" clause, say "respect to object or this".</li>
<li>In example, load from head should be "head.load(memory_order_relaxed)", because people are going to use example as example of good code.</li>
</ol>

<p>
<i>(wording edits not yet applied)</i>
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
Handed over to SG1.
</p>

<p><i>[2015-05 Lenexa, SG1 response]</i></p>

<p>
We believed we were done with it, but it was kicked back to us, with the wording we suggested not yet applied.  It may have been that our suggestions were unclear.  Was that the concern?
</p>

<p><i>[2016-02 Jacksonville]</i></p>

<p>
Applied the other half of the "if and only if" response from SG1, and moved to Ready.
</p>



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

<ol>
<li><p>Edit 29.6.5 [atomics.types.operations.req] p21 as indicated:</p>

<blockquote>
<p>
-21- <i>Effects</i>: <ins>Retrieves the value in <tt>expected</tt>. It then a</ins><del>A</del>tomically<del>,</del> 
compares the contents of the memory pointed to by <tt>object</tt> or by <tt>this</tt> for equality with that 
<del>in</del><ins>previously retrieved from</ins> <tt>expected</tt>, and if true, replaces the contents of the 
memory pointed to by <tt>object</tt> or by <tt>this</tt> with that in <tt>desired</tt><del>, and if false, 
updates the contents of the memory in expected with the contents of the memory pointed to by <tt>object</tt> 
or by <tt>this</tt>. Further, if</del><ins>. If and only if</ins> the comparison is true, memory is affected according to the value of 
<tt>success</tt>, and if the comparison is false, memory is affected according to the value of <tt>failure</tt>. 
When only one <tt>memory_order</tt> argument is supplied, the value of <tt>success</tt> is <tt>order</tt>, 
and the value of <tt>failure</tt> is <tt>order</tt> except that a value of <tt>memory_order_acq_rel</tt>
shall be replaced by the value <tt>memory_order_acquire</tt> and a value of <tt>memory_order_release</tt> shall
be replaced by the value <tt>memory_order_relaxed</tt>. <ins>If and only if the comparison is false then, after the atomic
operation, the contents of the memory in <tt>expected</tt> are replaced by the value read from <tt>object</tt> or
by <tt>this</tt> during the atomic comparison.</ins> If the operation returns true, these operations are
atomic read-modify-write operations (1.10) <ins>on the memory pointed to by <tt>this</tt> or 
<tt>object</tt></ins>. Otherwise, these operations are atomic load operations <ins>on that memory</ins>.
</p>
</blockquote>
</li>

<li><p>Add the following example to the end of 29.6.5 [atomics.types.operations.req] p23:</p>

<blockquote>
<p>
-23- [<i>Note</i>: [&hellip;] &mdash; <i>end note</i>] [<i>Example</i>: [&hellip;] &mdash; <i>end example</i>]
<p/>
<ins>[<i>Example</i>: Because the expected value is updated only on failure,
code releasing the memory containing the <tt>expected</tt> value
on success will work. E.g. list head insertion will act atomically
and would not introduce a data race in the following code:</ins>
</p>
<blockquote>
<pre><ins>
do {
  p-&gt;next = head; // make new list node point to the current head
} while(!head.compare_exchange_weak(p-&gt;next, p)); // try to insert
</ins></pre>
</blockquote>
<p>
<ins>&mdash; <i>end example</i>]</ins>
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2436" href="#2436">2436.</a> Comparators for associative containers should always be <tt>CopyConstructible</tt></h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts], 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2016-03-04</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</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 associative container requirements attempt to permit comparators that are <tt>DefaultConstructible</tt> 
but non-<tt>CopyConstructible</tt>. However, the Standard contradicts itself. 23.4.4.1 [map.overview] depicts 
<tt>map() : map(Compare()) { }</tt> which requires both <tt>DefaultConstructible</tt> and <tt>CopyConstructible</tt>.
<p/>
Unlike fine-grained element requirements (which are burdensome for implementers, but valuable for users), such 
fine-grained comparator requirements are both burdensome for implementers (as the Standard's self-contradiction 
demonstrates) and worthless for users. We should unconditionally require <tt>CopyConstructible</tt> comparators.  
(Note that <tt>DefaultConstructible</tt> should remain optional; this is not problematic for implementers, and 
allows users to use lambdas.)
<p/>
Key equality predicates for unordered associative containers are also affected. However, 17.6.3.4 [hash.requirements]/1 
already requires hashers to be <tt>CopyConstructible</tt>, so 23.2.5 [unord.req]'s redundant wording should 
be removed.
</p>

<p><i>[2015-02, Cologne]</i></p>

<p>
GR: I prefer to say "<tt>Compare</tt>" rather than "<tt>X::key_compare</tt>", since the former is what the user supplies. 
JY: It makes sense to use "<tt>Compare</tt>" when we talk about requirements but "<tt>key_compare</tt>" when we use it. 
<p/>
AM: We're adding requirements here, which is a breaking change, even though nobody will ever have had a non-<tt>CopyConstructible</tt> 
comparator. But the simplification is probably worth it.
<p/>
GR: I don't care about unmovable containers. But I do worry that people might want to move they comparators. MC: How do 
you reconcile that with the function that says "give me the comparator"? GR: That one returns by value? JY: Yes. [To MC] 
You make it a requirement of that function. [To GR] And it [the <tt>key_comp()</tt> function] is missing its requirements. 
We need to add them everywhere. GR: map already has the right requirements.
<p/>
JM: I dispute this. If in C++98 a type wasn't copyable, it had some interesting internal state, but in C++98 you wouldn't 
have been able to pass it into the container since you would have had to make a copy. JY: No, you could have 
default-constructed it and never moved it, e.g. a mutex. AM: So, it's a design change, but one that we should make. 
That's probably an LEWG issue. AM: There's a contradiction in the Standard here, and we need to fix it one way or another.
<p/>
<b>Conclusion</b>: Move to LEWG 
</p>

<p><i>[2016-03, Jacksonville]</i></p>

<p>
Adding <tt>CopyConstructible</tt> requirement OK.
<p/>
Unanimous yes.
<p/>
We discussed allowing <tt>MoveConstructible</tt>. A moved-from <tt>set&lt;&gt;</tt> might still contain elements, 
and using them would become undefined if the comparator changed behavior.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N3936.
</p>

<ol>
<li><p>Change 23.2.4 [associative.reqmts] Table 102 as indicated (Editorial note: For "expression" <tt>X::key_compare</tt> 
"defaults to" is redundant with the class definitions for map/etc.):</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Associative container requirements</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td>
<tt>X::key_compare</tt>
</td>
<td>
<tt>Compare</tt>
</td>
<td>
<del>defaults to <tt>less&lt;key_type&gt;</tt></del><br/>
<ins><i>Requires</i>: <tt>key_compare</tt> is <tt>CopyConstructible</tt>.</ins>
</td>
<td>
compile time
</td>
</tr>

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

<tr>
<td>
<tt>X(c)<br/>
X a(c);</tt>
</td>
<td>
</td>
<td>
<del><i>Requires</i>: <tt>key_compare</tt> is <tt>CopyConstructible</tt>.</del><br/>
<i>Effects</i>: Constructs an empty
container. Uses a copy of <tt>c</tt> as
a comparison object.
</td>
<td>
constant
</td>
</tr>

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

<tr>
<td>
<tt>X(i,j,c)<br/>
X a(i,j,c);</tt>
</td>
<td>
</td>
<td>
<i>Requires</i>: <del><tt>key_compare</tt> is <tt>CopyConstructible</tt>.</del><br/>
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
<i>Effects</i>: Constructs [&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

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

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

<li><p>Change 23.2.5 [unord.req] Table 103 as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 103 &mdash; Unordered associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td>
<tt>X::key_equal</tt>
</td>
<td>
<tt>Pred</tt>
</td>
<td>
<ins><i>Requires</i>: <tt>Pred</tt> is <tt>CopyConstructible</tt>.</ins><br/>
<tt>Pred</tt> shall be a binary predicate that takes two arguments of type <tt>Key</tt>.<br/> 
<tt>Pred</tt> is an equivalence relation.
</td>
<td>
compile time
</td>
</tr>

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

<tr>
<td>
<tt>X(n, hf, eq)<br/>
X a(n, hf, eq);</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
<del><i>Requires</i>: <tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.</del><br/>
<i>Effects</i>: Constructs [&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

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

<tr>
<td>
<tt>X(n, hf)<br/>
X a(n, hf);</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
<i>Requires</i>: <del><tt>hasher</tt> is <tt>CopyConstructible</tt> and</del><br/>
<tt>key_equal</tt> is <tt>DefaultConstructible</tt><br/>
<i>Effects</i>: Constructs [&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

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

<tr>
<td>
<tt>X(i, j, n, hf, eq)<br/>
X a(i, j, n, hf, eq);</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
<i>Requires</i>: <del><tt>hasher</tt> and <tt>key_equal</tt> are <tt>CopyConstructible</tt>.</del><br/>
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
<i>Effects</i>: Constructs [&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

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

<tr>
<td>
<tt>X(i, j, n, hf)<br/>
X a(i, j, n, hf);</tt>
</td>
<td>
<tt>X</tt>
</td>
<td>
<i>Requires</i>: <del><tt>hasher</tt> is <tt>CopyConstructible</tt> and</del><br/>
<tt>key_equal</tt> is <tt>DefaultConstructible</tt><br/>
<tt>value_type</tt> is <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt>.<br/>
<i>Effects</i>: Constructs [&hellip;]
</td>
<td>
[&hellip;]
</td>
</tr>

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

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






<hr>
<h3><a name="2441" href="#2441">2441.</a> Exact-width atomic typedefs should be provided</h3>
<p><b>Section:</b> 29.5 [atomics.types.generic] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Stephan T. Lavavej <b>Opened:</b> 2014-10-01 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#atomics.types.generic">active issues</a> in [atomics.types.generic].</p>
<p><b>View all other</b> <a href="lwg-index.html#atomics.types.generic">issues</a> in [atomics.types.generic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>&lt;atomic&gt;</tt> doesn't provide counterparts for <tt>&lt;inttypes.h&gt;</tt>'s most useful typedefs, possibly 
because they're quasi-optional. We can easily fix this.
</p>

<p><i>[2014-11, Urbana]</i></p>

<p>
Typedefs were transitional compatibility hack. Should use <tt>_Atomic</tt> macro or template.
E.g. <tt>_Atomic(int8_t)</tt>. BUT <tt>_Atomic</tt> disappeared!</p>

<p>
Detlef will look for <tt>_Atomic</tt> macro. If missing, will open issue.
</p>

<p><i>[2014-11-25, Hans comments]</i></p>

<p>
There is no <tt>_Atomic</tt> in C++. This is related to the much more general unanswered question of whether C++17 
should reference C11, C99, or neither.
</p>

<p><i>[2015-02 Cologne]</i></p>

<p>
AM: I think this is still an SG1 issue; they need to deal with it before we do.
</p>

<p><i>[2015-05 Lenexa, SG1 response]</i></p>

<p>
Move to SG1-OK status. This seems like an easy short-term fix. We probably need a paper on C/C++ atomics compatibility 
to deal with <tt>_Atomic</tt>, but that's a separable issue.
</p>

<p><i>[2015-10 pre-Kona]</i></p>

<p>
SG1 hands this over to LWG for wording review
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N3936.
</p>

<ol>
<li><p>Change 29.5 [atomics.types.generic] p8 as depicted:</p>

<blockquote>
<p>
-8- There shall be atomic typedefs corresponding to the typedefs in the header <tt>&lt;inttypes.h&gt;</tt> as specified in
Table 147. <ins><tt>atomic_int<i>N</i>_t</tt>, <tt>atomic_uint<i>N</i>_t</tt>, <tt>atomic_intptr_t</tt>, and 
<tt>atomic_uintptr_t</tt> shall be defined if and only if <tt>int<i>N</i>_t</tt>, <tt>uint<i>N</i>_t</tt>, <tt>intptr_t</tt>, 
and <tt>uintptr_t</tt> are defined, respectively.</ins>
</p>
</blockquote></li>

<li><p>Change 29.6.5 [atomics.types.operations.req], Table 147 ("<tt>atomic</tt> <tt>&lt;inttypes.h&gt;</tt> 
typedefs"), as depicted:</p>

<blockquote>
<table border="1">
<caption>Table 147 &mdash; <tt>atomic</tt> <tt>&lt;inttypes.h&gt;</tt> typedefs</caption>
<tr>
<th>Atomic typedef</th>
<th><tt>&lt;inttypes.h&gt;</tt> type</th>
</tr>

<tr>
<td>
<ins><tt>atomic_int8_t</tt></ins>
</td>
<td>
<ins><tt>int8_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_uint8_t</tt></ins>
</td>
<td>
<ins><tt>uint8_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_int16_t</tt></ins>
</td>
<td>
<ins><tt>int16_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_uint16_t</tt></ins>
</td>
<td>
<ins><tt>uint16_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_int32_t</tt></ins>
</td>
<td>
<ins><tt>int32_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_uint32_t</tt></ins>
</td>
<td>
<ins><tt>uint32_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_int64_t</tt></ins>
</td>
<td>
<ins><tt>int64_t</tt></ins>
</td>
</tr>

<tr>
<td>
<ins><tt>atomic_uint64_t</tt></ins>
</td>
<td>
<ins><tt>uint64_t</tt></ins>
</td>
</tr>

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

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






<hr>
<h3><a name="2451" href="#2451">2451.</a> [fund.ts.v2] <tt>optional&lt;T&gt;</tt> should 'forward' <tt>T</tt>'s implicit conversions</h3>
<p><b>Section:</b> 5.3 [fund.ts.v2::optional.object] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Geoffrey Romer <b>Opened:</b> 2014-10-31 <b>Last modified:</b> 2016-03-04</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::optional.object">active issues</a> in [fund.ts.v2::optional.object].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::optional.object">issues</a> in [fund.ts.v2::optional.object].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
Code such as the following is currently ill-formed (thanks to STL for the compelling example):
</p>
<blockquote><pre>
optional&lt;string&gt; opt_str = "meow";
</pre></blockquote>
<p>
This is because it would require two user-defined conversions (from <tt>const char*</tt> to <tt>string</tt>, 
and from <tt>string</tt> to <tt>optional&lt;string&gt;</tt>) where the language permits only one. This is 
likely to be a surprise and an inconvenience for users.
<p/>
<tt>optional&lt;T&gt;</tt> should be implicitly convertible from any <tt>U</tt> that is implicitly convertible 
to <tt>T</tt>. This can be implemented as a non-explicit constructor template <tt>optional(U&amp;&amp;)</tt>, 
which is enabled via SFINAE only if <tt>is_convertible_v&lt;U, T&gt;</tt> and <tt>is_constructible_v&lt;T, U&gt;</tt>, 
plus any additional conditions needed to avoid ambiguity with other constructors (see 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4064.html">N4064</a>, particularly the 
"Odd" example, for why <tt>is_convertible</tt> and <tt>is_constructible</tt> are both needed; thanks to Howard 
Hinnant for spotting this). 
<p/>
In addition, we may want to support explicit construction from <tt>U</tt>, which would mean providing a corresponding 
explicit constructor with a complementary SFINAE condition (this is the single-argument case of the "perfect 
initialization" pattern described in N4064).
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>STL: This has status LEWG, but it should be priority 1, since we cannot ship an IS without this. </p>
<p>TK: We assigned our own priorities to LWG-LEWG issues, but haven't actually processed any issues yet. </p>
<p>MC: This is important.</p>

<p><i>[2016-02-17, Ville comments and provides concrete wording]</i></p>

<p>
I have prototype-implemented this wording in libstdc++. I didn't edit
the copy/move-assignment operator tables into the new
<tt>operator=</tt> templates that take <tt>optional</tt>s of a different
type; there's a drafting note that suggests copying them
from the existing tables.
</p>

<p><i>[2016-03, Jacksonville]</i></p>

<p>
Discussion of whether <tt>variant</tt> supports this. We think it does.
<p/>
Take it for C++17.
<p/>
Unanimous yes.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html">N4562</a>.
</p>

<ol>
<li><p>Edit 5.3 [optional.object] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt;
class optional
{
public:
  typedef T value_type;
  
  <i>// 5.3.1, Constructors</i>
  constexpr optional() noexcept;
  constexpr optional(nullopt_t) noexcept;
  optional(const optional&amp;);
  optional(optional&amp;&amp;) noexcept(<i>see below</i>);
  constexpr optional(const T&amp;);
  constexpr optional(T&amp;&amp;);
  template &lt;class... Args&gt; constexpr explicit optional(in_place_t, Args&amp;&amp;...);
  template &lt;class U, class... Args&gt;
    constexpr explicit optional(in_place_t, initializer_list&lt;U&gt;, Args&amp;&amp;...);
  <ins>template &lt;class U&gt; constexpr optional(U&amp;&amp;);
  template &lt;class U&gt; constexpr optional(const optional&lt;U&gt;&amp;);
  template &lt;class U&gt; constexpr optional(optional&lt;U&gt;&amp;&amp;);</ins>
  
  [&hellip;]
  
  <i>// 5.3.3, Assignment</i>
  optional&amp; operator=(nullopt_t) noexcept;
  optional&amp; operator=(const optional&amp;);
  optional&amp; operator=(optional&amp;&amp;) noexcept(see below);
  template &lt;class U&gt; optional&amp; operator=(U&amp;&amp;);
  <ins>template &lt;class U&gt; optional&amp; operator=(const optional&lt;U&gt;&amp;);
  template &lt;class U&gt; optional&amp; operator=(optional&lt;U&gt;&amp;&amp;);</ins>
  template &lt;class... Args&gt; void emplace(Args&amp;&amp;...);
  template &lt;class U, class... Args&gt;
    void emplace(initializer_list&lt;U&gt;, Args&amp;&amp;...);

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

</li>

<li><p>In 5.3.1 [optional.object.ctor], insert new signature specifications after p33:</p>

<blockquote>
<p>
<ins>[<i>Note</i>: The following constructors are conditionally specified as <tt>explicit</tt>. This is typically 
implemented by declaring two such constructors, of which at most one participates in overload resolution. &mdash; 
<i>end note</i>]</ins>
</p>
<pre>
<ins>template &lt;class U&gt;
constexpr optional(U&amp;&amp; v);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Initializes the contained value as if direct-non-list-initializing an object of type <tt>T</tt> 
with the expression <tt>std::forward&lt;U&gt;(v)</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions</i>: <tt>*this</tt> contains a value.</ins>
<p/>
<ins>-?- <i>Throws</i>: Any exception thrown by the selected constructor of <tt>T</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor 
    shall be a <tt>constexpr</tt> constructor. This constructor shall not participate in overload resolution unless 
    <tt>is_constructible_v&lt;T, U&amp;&amp;&gt;</tt> is <tt>true</tt> and <tt>U</tt> is not the same type as <tt>T</tt>.
    The constructor is <tt>explicit</tt> if and only if <tt>is_convertible_v&lt;U&amp;&amp;, T&gt;</tt> is <tt>false</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template &lt;class U&gt;
constexpr optional(const optional&lt;U&gt;&amp; rhs);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: If <tt>rhs</tt> contains a value, initializes the contained value as if direct-non-list-initializing 
an object of type <tt>T</tt> with the expression <tt>*rhs</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions</i>: <tt>bool(rhs) == bool(*this)</tt>.</ins>
<p/>
<ins>-?- <i>Throws</i>: Any exception thrown by the selected constructor of <tt>T</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor shall 
be a <tt>constexpr</tt> constructor. This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, const U&amp;&gt;</tt> is <tt>true</tt>, <tt>is_same&lt;decay_t&lt;U&gt;, T&gt;</tt> is 
<tt>false</tt>, <tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt> and 
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>. The constructor is <tt>explicit</tt> 
if and only if <tt>is_convertible_v&lt;const U&amp;, T&gt;</tt> is <tt>false</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template &lt;class U&gt;
constexpr optional(optional&lt;U&gt;&amp;&amp; rhs);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: If <tt>rhs</tt> contains a value, initializes the contained value as if 
direct-non-list-initializing an object of type <tt>T</tt> with the expression <tt>std::move(*rhs)</tt>. 
<tt>bool(rhs)</tt> is unchanged.</ins>
<p/>
<ins>-?- <i>Postconditions</i>: <tt>bool(rhs) == bool(*this)</tt>.</ins>
<p/>
<ins>-?- <i>Throws</i>: Any exception thrown by the selected constructor of <tt>T</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor. This constructor shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, U&amp;&amp;&gt;</tt> is <tt>true</tt>, <tt>is_same&lt;decay_t&lt;U&gt;, T&gt;</tt> is 
<tt>false</tt>, <tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt> and 
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt> and <tt>U</tt> is not the same type 
as <tt>T</tt>. The constructor is <tt>explicit</tt> if and only if <tt>is_convertible_v&lt;U&amp;&amp;, T&gt;</tt>
is <tt>false</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 5.3.3 [optional.object.assign], change as indicated:</p>

<blockquote>
<pre>
template &lt;class U&gt; optional&lt;T&gt;&amp; operator=(U&amp;&amp; v);
</pre>
<blockquote>
<p>
-22- <i>Remarks:</i> If any exception is thrown, the result of the expression <tt>bool(*this)</tt> remains unchanged. 
If an exception is thrown during the call to <tt>T</tt>'s constructor, the state of <tt>v</tt> is determined by the 
exception safety guarantee of <tt>T</tt>'s constructor. If an exception is thrown during the call to <tt>T</tt>'s 
assignment, the state of <tt>*val</tt> and <tt>v</tt> is determined by the exception safety guarantee of <tt>T</tt>'s 
assignment. The function shall not participate in overload resolution unless 
<ins><ins><tt>decay_t&lt;U&gt;</tt> is not <tt>nullopt_t</tt> and <tt>decay_t&lt;U&gt;</tt> is not a specialization of 
<tt>optional</tt></ins></ins><del><tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt> is <tt>true</tt></del>.
<p/>
<del>-23- <i>Notes</i>: The reason for providing such generic assignment and then constraining it so that effectively 
<tt>T == U</tt> is to guarantee that assignment of the form <tt>o = {}</tt> is unambiguous.</del>
</p>
</blockquote>
<pre>
<ins>template &lt;class U&gt; optional&lt;T&gt;&amp; operator=(const optional&lt;U&gt;&amp; rhs);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: <tt>is_constructible_v&lt;T, const U&amp;&gt;</tt> is <tt>true</tt> and 
<tt>is_assignable_v&lt;T&amp;, const U&amp;&gt;</tt> is <tt>true</tt>.</ins>
<p/>
<ins>-?- <i>Effects</i>:</ins>
</p>
<table border="1">
<caption><ins>Table ? &mdash; <tt>optional::operator=(const optional&lt;U&gt;&amp;)</tt> effects</ins></caption>

<tr>
<th></th>
<th><ins><b><tt>*this</tt> contains a value</b></ins></th>
<th><ins><b><tt>*this</tt> does not contain a value</b></ins></th>
</tr>

<tr>
<td><ins><b><tt>rhs</tt> contains a value</b></ins></td>
<td><ins>assigns <tt>*rhs</tt> to the contained value</ins></td>
<td><ins>initializes the contained value as if direct-non-list-initializing an object of type 
<tt>T</tt> with <tt>*rhs</tt></ins></td>
</tr>

<tr>
<td><ins><b><tt>rhs</tt> does not contain a value</b></ins></td>
<td><ins>destroys the contained value by calling <tt>val-&gt;T::~T()</tt></ins></td>
<td><ins>no effect</ins></td>
</tr>

</table> 
<p>
<ins>-?- <i>Returns</i>: <tt>*this</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions</i>: <tt>bool(rhs) == bool(*this)</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: If any exception is thrown, the result of the expression <tt>bool(*this)</tt> remains unchanged. 
If an exception is thrown during the call to <tt>T</tt>'s constructor, the state of <tt>*rhs.val</tt> is determined by the 
exception safety guarantee of <tt>T</tt>'s constructor. If an exception is thrown during the call to <tt>T</tt>'s assignment, 
the state of <tt>*val</tt> and <tt>*rhs.val</tt> is determined by the exception safety guarantee of <tt>T</tt>'s assignment. 
The function shall not participate in overload resolution unless <tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt> is 
<tt>false</tt>.</ins>
</p>
</blockquote>
<pre>
<ins>template &lt;class U&gt; optional&lt;T&gt;&amp; operator=(optional&lt;U&gt;&amp;&amp; rhs);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: <tt>is_constructible_v&lt;T, U&gt;</tt> is <tt>true</tt> and 
<tt>is_assignable_v&lt;T&amp;, U&gt;</tt> is <tt>true</tt>.</ins>
<p/>
<ins>-?- <i>Effects</i>: The result of the expression <tt>bool(rhs)</tt> remains unchanged. </ins>
</p>
<table border="1">
<caption><ins>Table ? &mdash; <tt>optional::operator=(optional&lt;U&gt;&amp;&amp;)</tt> effects</ins></caption>

<tr>
<th></th>
<th><ins><b><tt>*this</tt> contains a value</b></ins></th>
<th><ins><b><tt>*this</tt> does not contain a value</b></ins></th>
</tr>

<tr>
<td><ins><b><tt>rhs</tt> contains a value</b></ins></td>
<td><ins>assigns <tt>std::move(*rhs)</tt> to the contained value</ins></td>
<td><ins>initializes the contained value as if direct-non-list-initializing an object of type 
<tt>T</tt> with <tt>std::move(*rhs)</tt></ins></td>
</tr>

<tr>
<td><ins><b><tt>rhs</tt> does not contain a value</b></ins></td>
<td><ins>destroys the contained value by calling <tt>val-&gt;T::~T()</tt></ins></td>
<td><ins>no effect</ins></td>
</tr>

</table> 
<p>
<ins>-?- <i>Returns</i>: <tt>*this</tt>.</ins>
<p/>
<ins>-?- <i>Postconditions</i>: <tt>bool(rhs) == bool(*this)</tt>.</ins>
<p/>
<ins>-?- <i>Remarks</i>: If any exception is thrown, the result of the expression <tt>bool(*this)</tt> remains unchanged. 
If an exception is thrown during the call to <tt>T</tt>'s constructor, the state of <tt>*rhs.val</tt> is determined by the 
exception safety guarantee of <tt>T</tt>'s constructor. If an exception is thrown during the call to <tt>T</tt>'s 
assignment, the state of <tt>*val</tt> and <tt>*rhs.val</tt> is determined by the exception safety guarantee of <tt>T</tt>'s 
assignment. The function shall not participate in overload resolution unless
<tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt> is <tt>false</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2509" href="#2509">2509.</a> [fund.ts.v2] <tt>any_cast</tt> doesn't work with rvalue reference targets and cannot move with a value target</h3>
<p><b>Section:</b> 6.4 [fund.ts.v2::any.nonmembers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-06-13 <b>Last modified:</b> 2016-04-15</p>
<p><b>Priority: </b>2
</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><b>Addresses: fund.ts.v2</b></p>
<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4480.html">Library Fundamentals v1</a>, 
[any.nonmembers]/5 says:
</p>
<blockquote><p>
For the first form, <tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. 
For the second and third forms, <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>.
</p></blockquote>
<ol>
<li><p>This means that</p>
<blockquote><pre>
any_cast&lt;Foo&amp;&amp;&gt;(<i>whatever_kind_of_any_lvalue_or_rvalue</i>);
</pre></blockquote>
<p>
is always ill-formed.  That's unfortunate, because forwarding such a cast
result of an <tt>any</tt> is actually useful, and such uses do not want to copy/move
the underlying value just yet.
</p>
</li>

<li><p>Another problem is that that same specification prevents an implementation
from moving to the target when</p>
<blockquote><pre>
ValueType any_cast(any&amp;&amp; operand);
</pre></blockquote>
<p>
is used. The difference is observable, so an implementation can't perform
an optimization under the as-if rule. We are pessimizing every <tt>CopyConstructible</tt>
<em>and</em> <tt>MoveConstructible</tt> type because we are not using the move when
we can. This unfortunately includes types such as the library containers,
and we do not want such a pessimization!
</p>
</li>
</ol>

<p><i>[2015-07, Telecom]</i></p>

<p>Jonathan to provide wording</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>Eric offered to help JW with wording</p>
<p>Move to Open</p>

<p><i>[2016-01-30, Ville comments and provides wording]</i></p>

<p>
Drafting note: the first two changes add support for types that have
explicitly deleted move constructors. Should we choose not to support
such types at all, the third change is all we need. For the second change,
there are still potential cases where <i>Requires</i> is fulfilled but <i>Effects</i>
is ill-formed, if a suitably concocted type is thrown into the mix.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html">N4562</a>.
</p>

<ol>
<li><p>In 6.3.1 [any.cons] p11+p12, edit as follows:</p>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  any(ValueType&amp;&amp; value);
</pre>
<blockquote>
<p>
-10- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
-11- <i>Requires</i>: <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements<ins>, except for the requirements 
for <tt>MoveConstructible</tt></ins>. If <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.
<p/>
-12- <i>Effects</i>: <ins>If <tt>is_constructible_v&lt;T, ValueType&amp;&amp;&gt;</tt> is true, c</ins><del>C</del>onstructs 
an object of type <tt>any</tt> that contains an object of type <tt>T</tt> direct-initialized with 
<tt>std::forward&lt;ValueType&gt;(value)</tt>. <ins>Otherwise, constructs an object of type <tt>any</tt> that contains an object of 
type <tt>T</tt> direct-initialized with <tt>value</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 6.4 [any.nonmembers] p5, edit as follows:</p>
<blockquote>
<pre>
template&lt;class ValueType&gt;
  ValueType any_cast(const any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp; operand);
template&lt;class ValueType&gt;
  ValueType any_cast(any&amp;&amp; operand);
</pre>
<blockquote>
<p>
-4- <i>Requires</i>: <tt>is_reference_v&lt;ValueType&gt;</tt> is <tt>true</tt> or <tt>is_copy_constructible_v&lt;ValueType&gt;</tt> 
is <tt>true</tt>. Otherwise the program is ill-formed. 
<p/>
-5- <i>Returns</i>: For the first form, <tt>*any_cast&lt;add_const_t&lt;remove_reference_t&lt;ValueType&gt;&gt;&gt;(&amp;operand)</tt>. 
For the second <del>and third</del> form<del>s</del>, <tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>. 
<ins>For the third form, if <tt>is_move_constructible_v&lt;ValueType&gt;</tt> is <tt>true</tt> and
<tt>is_lvalue_reference_v&lt;ValueType&gt;</tt> is <tt>false</tt>, 
<tt>std::move(*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand))</tt>, otherwise,
<tt>*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand)</tt>.</ins>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2516" href="#2516">2516.</a> [fund.ts.v2] Public "exposition only" members in <tt>observer_ptr</tt></h3>
<p><b>Section:</b> 8.12.1 [fund.ts.v2::memory.observer.ptr.overview] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-07-07 <b>Last modified:</b> 2016-03-06</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><b>Addresses: fund.ts.v2</b></p>
<p>
In <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a> 
[memory.observer.ptr.overview], the public member typedefs <tt>pointer</tt> and <tt>reference</tt> are marked 
"//exposition-only".
</p>
<p>
Clause 17 of the standard, which the TS incorporates by reference, only defines "exposition only" for private 
members (see 17.5.2.3 [objects.within.classes], also compare LWG <a href="lwg-active.html#2310">2310</a>). These types should 
be either made private, or not exposition only.
</p>

<p><i>[2015-07, Telecom]</i></p>

<p>
Geoffrey: Will survey "exposition-only" use and come up with wording to define "exposition-only" for data members, types, and concepts.
</p>

<p><i>[2015-10, Kona Saturday afternoon]</i></p>

<p>GR: I cannot figure out what "exposition only" means. JW explained it to me once as meaning that "it has the same normative effect as if the member existed, without the effect of there actually being a member". But I don't know what is the "normative effect of the existence of a member" is.</p>
<p>MC: The "exposition-only" member should be private. GR: But it still has normative effect. </p><p>GR, STL: Maybe the member is public so it can be used in the public section? WEB (original worder): I don't know why the member is public. I'm not averse to changing it. GR: A telecon instructed me to find out how [exposition-only] is used elsewhere, and I came back with this issue because I don't understand what it means.</p>
<p>STL: We use exposition-only in many places. We all know what it means. GR: I don't know precisely what means. </p><p>STL: I know exactly what it means. STL suggests a rewording: the paragraph already says what we want, it's just a little too precise. GR not sure.</p>
<p>WEB: Are there any non-members in the Standard that are "exposition only"? STL: DECAY_COPY and INVOKE. </p><p>GR: There are a few enums. </p><p>HH: We have nested class types that are exposition-only. HH: We're about to make "none_t" an exposition-only type. [Everyone lists some examples from the Standard that are EO.] GR: "bitmask" contains some hypothetical types. That potentially contains user requirements (since regexp requires certain trait members to be "bitmask types").</p>
<p>STL: What's the priority of this issue? Does this have any effect on implementations? Is there anything mysterious that could happen? </p><p>AM: 2. </p><p>STL: How did that happen? It's at best priority 4. We have so many better things we could be doing.</p>
<p>WEB: "exposition only" in [???] is just used as plain English, not as words of power. GR: That gives me enough to make wording to fix this. </p><p>STL: I wouldn't mind if we didn't fix this ever.</p>
<p>MC: @JW, please write up wording for <a href="lwg-active.html#2310">2310</a> to make the EO members private. JW: I can't do that, because that'd make the class a non-aggregate. </p><p>WEB: Please cross-link both issues and move 2516 to "open".</p>

<p><i>[2015-11-14, Geoffrey Romer provides wording]</i></p>


<p><i>[2016-03 Jacksonville]</i></p>

<p>
Move to ready. Note that this modifies both the Draft Standard and LFTS 2
</p>


<p><b>Proposed resolution:</b></p>
<ol style="list-style-type:upper-alpha">
<li>
<p>This part of the wording is against the working draft of the standard for Programming Language C++, the wording is 
relative to N4567.</p>
<ol>
<li><p>Edit 17.5.2.3 [objects.within.classes]/p2 as follows:</p>
<blockquote><p>
-2- <del>Objects of certain classes are sometimes required by the external specifications of their classes to store data,
apparently in member objects.</del> For the sake of exposition, some subclauses provide representative declarations,
and semantic requirements, for private member<ins>s</ins> <del>objects</del> of classes that meet the external specifications
of the classes. The declarations for such member<ins>s</ins> <del>objects and the definitions of related member types</del> are
followed by a comment that ends with <i>exposition only</i>, as in:
</p>
<blockquote><pre>
streambuf* sb; <i>// exposition only</i>
</pre></blockquote>
</blockquote>
</li>

</ol>
</li>

<li>
<p>This part of the wording is against the working draft of the C++ Extensions for Library Fundamentals, Version 2, 
the wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a></p>
<ol>
<li><p>Edit the synopsis in 8.12.1 [memory.observer.ptr.overview] as follows:</p>

<blockquote>
<pre>
namespace std {
namespace experimental {
inline namespace fundamentals_v2 {

  template &lt;class W&gt; class observer_ptr {
    <ins>using pointer = add_pointer_t&lt;W&gt;;            <i>// exposition-only</i>
    using reference = add_lvalue_reference_t&lt;W&gt; <i>// exposition-only</i></ins>
  public:
    // publish our template parameter and variations thereof
    using element_type = W;
    <del>using pointer = add_pointer_t&lt;W&gt;;            <i>// exposition-only</i>
    using reference = add_lvalue_reference_t&lt;W&gt; <i>// exposition-only</i></del>

    <i>// 8.12.2, observer_ptr constructors
    // default c'tor</i>
    constexpr observer_ptr() noexcept;

    [&hellip;]
  }; // observer_ptr&lt;&gt;

} // inline namespace fundamentals_v2
} // namespace experimental
} // namespace std
</pre>
</blockquote>
</li>
</ol>
</li>
</ol>





<hr>
<h3><a name="2542" href="#2542">2542.</a> Missing <tt>const</tt> requirements for associative containers</h3>
<p><b>Section:</b> 23.2.4 [associative.reqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2015-09-26 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#associative.reqmts">active issues</a> in [associative.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#associative.reqmts">issues</a> in [associative.reqmts].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Table 101 &mdash; "Associative container requirements" and its associated legend paragraph 
23.2.4 [associative.reqmts] p8 omits to impose constraints related to <tt>const</tt>
values, contrary to unordered containers as specified by Table 102 and its associated legend 
paragraph p11.
<p/>
Reading these requirements strictly, a feasible associative container could declare several
conceptual observer members &mdash; for example <tt>key_comp()</tt>, <tt>value_comp()</tt>, 
or <tt>count()</tt> &mdash; as non-<tt>const</tt> functions. In Table 102, "possibly <tt>const</tt>" 
values are exposed by different symbols, so the situation for unordered containers is clear
that these functions may be invoked by <tt>const</tt> container objects.
<p/>
For the above mentioned member functions this problem is only minor, because the synopses of the 
actual Standard associative containers do declare these members as <tt>const</tt> functions, but 
nonetheless a wording fix is recommended to clean up the specification asymmetry between associative 
containers and unordered containers.
<p/>
The consequences of the ignorance of <tt>const</tt> becomes much worse when we consider a code 
example such as the following one from a recent 
<a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67617">libstdc++ bug report</a>:
</p>
<blockquote><pre>
#include &lt;set&gt;

struct compare 
{
  bool operator()(int a, int b) // Notice the <span style="color:#C80000;font-weight:bold"><em>non-<tt>const</tt></em></span> member declaration!
  {
    return a &lt; b;
  }
};

int main() {
  const std::set&lt;int, compare&gt; s;
  s.find(0);
}
</pre></blockquote>
<p>
The current wording in 23.2.4 [associative.reqmts] can be read to require this code to be well-formed,
because there is no requirement that an object <tt>comp</tt> of the ordering relation of type <tt>Compare</tt>
might be a <tt>const</tt> value when the function call expression <tt>comp(k1, k2)</tt> is evaluated.
<p/>
Current implementations differ: While Clangs libc++ and GCCs libstdc++ reject the above example,
the Dinkumware library associated with Visual Studio 2015 accepts it.
<p/>
I believe the current wording unintentionally misses the constraint that even <tt>const</tt> comparison
function objects of associative containers need to support the predicate call expression. This becomes
more obvious when considering the member <tt>value_compare</tt> of <tt>std::map</tt> which provides (only) a
<tt>const operator()</tt> overload which invokes the call expression of data member <tt>comp</tt>.
</p>

<p><i>[2016-02-20, Daniel comments and extends suggested wording]</i></p>

<p>
It has been pointed out to me, that the suggested wording is a potentially breaking change and should therefore
be mentioned in Annex C.
<p/>
First, let me emphasize that this potentially breaking change is <em>solely</em> caused by the wording change in
23.2.4 [associative.reqmts] p8:
</p>
<blockquote>
<p>
[&hellip;] and <tt>c</tt> denotes a <ins>possibly <tt>const</tt></ins> value of type <tt>X::key_compare</tt>; [&hellip;]
</p>
</blockquote>
<p>
So, even if that proposal would be rejected, the rest of the suggested changes could (and should) be
considered for further evaluation, because the remaining parts do just repair an obvious mismatch between
the concrete associative containers (<tt>std::set</tt>, <tt>std::map</tt>, &hellip;) and the requirement
tables.
<p/>
Second, I believe that the existing wording was never really clear in regard to <em>require</em> a Standard Library
to accept comparison functors with non-<tt>const operator()</tt>. If the committee really intends to require
a Library to support comparison functors with non-<tt>const operator()</tt>, this should be clarified by at least
an additional note to e.g. 23.2.4 [associative.reqmts] p8.
</p>

<p><i>[2016-03, Jacksonville]</i></p>

Move to Ready with Daniel's updated wording


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4567.</p>

<ol>
<li><p>Change 23.2.4 [associative.reqmts] p8 as indicated:</p>
<blockquote>
<p>
-8- In Table 101, <tt>X</tt> denotes an associative container class, <tt>a</tt> denotes a value of type 
<tt>X</tt>, <ins><tt>b</tt> denotes a possibly <tt>const</tt> value of type <tt>X</tt>,</ins> <tt>u</tt> denotes 
the name of a variable being declared, <tt>a_uniq</tt> denotes a value of 
type <tt>X</tt> when <tt>X</tt> supports unique keys, <tt>a_eq</tt> denotes a value of type <tt>X</tt> when 
<tt>X</tt> supports multiple keys, <tt>a_tran</tt> denotes a <ins>possibly <tt>const</tt></ins> value of type 
<tt>X</tt> when the <i>qualified-id</i> <tt>X::key_compare::is_transparent</tt> is valid and denotes a type (14.8.2), 
<tt>i</tt> and <tt>j</tt> satisfy input iterator requirements and refer to elements implicitly convertible to 
<tt>value_type</tt>, 
<tt>[i, j)</tt> denotes a valid range, <tt>p</tt> denotes a valid const iterator to <tt>a</tt>, <tt>q</tt> 
denotes a valid dereferenceable const iterator to <tt>a</tt>, <tt>r</tt> denotes a valid
dereferenceable iterator to <tt>a</tt>, <tt>[q1, q2)</tt> denotes a valid range of const iterators in <tt>a</tt>, 
<tt>il</tt> designates an object of type <tt>initializer_list&lt;value_type&gt;</tt>, <tt>t</tt> denotes a 
value of type <tt>X::value_type</tt>, <tt>k</tt> denotes a value of type <tt>X::key_type</tt> and <tt>c</tt> 
denotes a <ins>possibly <tt>const</tt></ins> value of type <tt>X::key_compare</tt>; <tt>kl</tt> is a value such that <tt>a</tt> is
partitioned (25.4) with respect to <tt>c(r, kl)</tt>, with <tt>r</tt> the key value of <tt>e</tt> and <tt>e</tt> 
in <tt>a</tt>; <tt>ku</tt> is a value such that <tt>a</tt> is partitioned with respect to <tt>!c(ku, r)</tt>; 
<tt>ke</tt> is a value such that <tt>a</tt> is partitioned with respect to <tt>c(r, ke)</tt> and <tt>!c(ke, r)</tt>, 
with <tt>c(r, ke)</tt> implying <tt>!c(ke, r)</tt>. <tt>A</tt> denotes the storage allocator used by <tt>X</tt>, 
if any, or <tt>std::allocator&lt;X::value_type&gt;</tt> otherwise, and <tt>m</tt> denotes an allocator of a 
type convertible to <tt>A</tt>.
</p>
</blockquote>
</li>

<li><p>Change 23.2.4 [associative.reqmts], Table 101 &mdash; "Associative container requirements" as indicated: 
<p/>
[<i>Editorial note</i>: This issue doesn't touch the note column entries for the expressions related to <tt>key_comp()</tt>
and <tt>value_comp()</tt> (except for the symbolic correction), since these are already handled by LWG issues 
<a href="lwg-active.html#2227">2227</a> and <a href="lwg-active.html#2215">2215</a> &mdash; <i>end editorial note</i>]
</p>

<blockquote>
<table border="1">
<caption>Table 101 &mdash; Associative container requirements (in addition to container) (continued)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.key_comp()</tt>
</td>
<td>
<tt>X::key_compare</tt>
</td>
<td>
returns the comparison object<br/>
out of which <tt><del>a</del><ins>b</ins></tt> was<br/>
constructed.
</td>
<td>
constant
</td>
</tr>

<tr>
<td>
<tt><del>a</del><ins>b</ins>.value_comp()</tt>
</td>
<td>
<tt>X::value_compare</tt>
</td>
<td>
returns an object of<br/>
<tt>value_compare</tt> constructed<br/>
out of the comparison object
</td>
<td>
constant
</td>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.find(k)</tt>
</td>
<td>
<tt>iterator</tt>;<br/>
<tt>const_iterator</tt> for constant <tt><del>a</del><ins>b</ins></tt>.
</td>
<td>
returns an iterator pointing to<br/>
an element with the key<br/>
equivalent to <tt>k</tt>, or <tt><del>a</del><ins>b</ins>.end()</tt> if<br/>
such an element is not found
</td>
<td>
logarithmic
</td>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.count(k)</tt>
</td>
<td>
<tt>size_type</tt>
</td>
<td>
returns the number of elements<br/>
with key equivalent to <tt>k</tt>
</td>
<td>
<tt>log(<del>a</del><ins>b</ins>.size()) + <del>a</del><ins>b</ins>.count(k)</tt>
</td>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.lower_bound(k)</tt>
</td>
<td>
<tt>iterator</tt>;<br/>
<tt>const_iterator</tt> for constant <tt><del>a</del><ins>b</ins></tt>.
</td>
<td>
returns an iterator pointing to<br/>
the first element with key not<br/>
less than <tt>k</tt>, or <tt><del>a</del><ins>b</ins>.end()</tt> if such<br/>
an element is not found.
</td>
<td>
logarithmic
</td>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.upper_bound(k)</tt>
</td>
<td>
<tt>iterator</tt>;<br/>
<tt>const_iterator</tt> for constant <tt><del>a</del><ins>b</ins></tt>.
</td>
<td>
returns an iterator pointing to<br/>
the first element with key<br/>
greater than <tt>k</tt>, or <tt><del>a</del><ins>b</ins>.end()</tt> if<br/>
such an element is not found.
</td>
<td>
logarithmic
</td>
</tr>

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

<tr>
<td>
<tt><del>a</del><ins>b</ins>.equal_range(k)</tt>
</td>
<td>
<tt>pair&lt;iterator, iterator&gt;</tt>;<br/>
<tt>pair&lt;const_iterator, const_iterator&gt;</tt> for<br/>
constant <del>a</del><ins>b</ins>.
</td>
<td>
equivalent to <tt>make_-<br/>
pair(<del>a</del><ins>b</ins>.lower_bound(k),<br/>
<del>a</del><ins>b</ins>.upper_bound(k))</tt>.
</td>
<td>
logarithmic
</td>
</tr>

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

</table>
</blockquote>

</li>

<li><p>Add a new entry to Annex C, C.4 [diff.cpp14], as indicated:</p>

<blockquote>
<p>
<ins>C.4.4 Clause 23: containers library [diff.cpp14.containers]</ins>
<p/>
<ins>23.2.4</ins>
<p/>
<ins><b>Change:</b> Requirements change: </ins>
<p/>
<ins><b>Rationale:</b> Increase portability, clarification of associative container requirements.</ins>
<p/>
<ins><b>Effect on original feature:</b> Valid 2014 code that attempts to use associative containers 
having a comparison object with non-<tt>const</tt> function call operator may fail to compile:</ins>
</p>
<blockquote><pre>
<ins>#include &lt;set&gt;

struct compare 
{
  bool operator()(int a, int b)
  {
    return a &lt; b;
  }
};

int main() {
  const std::set&lt;int, compare&gt; s;
  s.find(0);
}</ins>
</pre></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2549" href="#2549">2549.</a> Tuple <i>EXPLICIT</i> constructor templates that take <tt>tuple</tt> parameters end up taking references 
to temporaries and will create dangling references</h3>
<p><b>Section:</b> 20.4.2.1 [tuple.cnstr] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-10-11 <b>Last modified:</b> 2016-03-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#tuple.cnstr">active issues</a> in [tuple.cnstr].</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.cnstr">issues</a> in [tuple.cnstr].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Consider this example:
</p>
<blockquote><pre>
#include &lt;utility&gt;
#include &lt;tuple&gt;

struct X {
  int state; // this has to be here to not allow tuple
             // to inherit from an empty X.
  X() {
  }

  X(X const&amp;) {
  }

  X(X&amp;&amp;) {
  }

  ~X() {
  }
};

int main()
{
  X v;
  std::tuple&lt;X&gt; t1{v};
  std::tuple&lt;std::tuple&lt;X&gt;&amp;&amp;&gt; t2{std::move(t1)}; // #1
  std::tuple&lt;std::tuple&lt;X&gt;&gt; t3{std::move(t2)}; // #2
}
</pre></blockquote>
<p>
The line marked with <tt>#1</tt> will use the constructor
<tt>template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);</tt>
and will construct a temporary and bind an rvalue reference to it.
The line marked with <tt>#2</tt> will move from a dangling reference.
<p/>
In order to solve the problem, the constructor templates taking tuples
as parameters need additional SFINAE conditions that SFINAE
those constructor templates away when <tt>Types...</tt> is constructible
or convertible from the incoming tuple type and <tt>sizeof...(Types)</tt> equals
one. libstdc++ already has this fix applied.
<p/>
There is an additional check that needs to be done, in order to avoid
infinite meta-recursion during overload resolution, for a case where
the element type is itself constructible from the target tuple. An example
illustrating that problem is as follows:
</p>
<blockquote><pre>
#include &lt;tuple&gt;

struct A
{
  template &lt;typename T&gt;
  A(T)
  {
  }

  A(const A&amp;) = default;
  A(A&amp;&amp;) = default;
  A&amp; operator=(const A&amp;) = default;
  A&amp; operator=(A&amp;&amp;) = default;
  ~A() = default;
};

int main()
{
  auto x = A{7};
  std::make_tuple(x);
}
</pre></blockquote>
<p>
I provide two proposed resolutions, one that merely has a note encouraging
trait-based implementations to avoid infinite meta-recursion, and a second
one that avoids it normatively (implementations can still do things differently
under the as-if rule, so we are not necessarily overspecifying how to do it.)
</p>

<p><i>[2016-02-17, Ville comments]</i></p>

<p>
It was pointed out at <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69853">gcc bug 69853</a>
that the fix for LWG 2549 is a breaking change. That is, it breaks code
that expects constructors inherited from <tt>tuple</tt> to provide an implicit
base-to-derived conversion. I think that's just additional motivation
to apply the fix; that conversion is very much undesirable. The example
I wrote into the bug report is just one example of a very subtle temporary
being created.
</p>

<p><strong>Previous resolution from Ville [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol style="list-style-type:upper-alpha">
<li><p><b>Alternative 1:</b></p>
<ol>
<li><p>In 20.4.2.1 [tuple.cnstr]/17, edit as follows:</p>
<blockquote>
<pre>
template &lt;class... UTypes> <i>EXPLICIT</i> constexpr tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p><tt>is_constructible&lt;T<sub><i>i</i></sub>, const Ui&amp;&gt;::value</tt> is true for all 
<tt><i>i</i></tt><del>.</del><ins>, and</ins></p></li>
<li><p><ins><tt>sizeof...(Types) != 1</tt>, or <tt>is_convertible&lt;const tuple&lt;UTypes...&gt;&amp;,
Types...&gt;::value</tt> is false and <tt>is_constructible&lt;Types..., const tuple&lt;UTypes...&gt;&amp;&gt;::value</tt>
is false.</ins></p></li>
</ul>
<p>
<ins>
[<i>Note</i>: to avoid infinite template recursion in a trait-based implementation
for the case where <tt>UTypes...</tt> is a single type that has a constructor template that accepts
<tt>tuple&lt;Types...&gt;</tt>, implementations need to additionally check that
<tt>remove_cv_t&lt;remove_reference_t&lt;const tuple&lt;UTypes...&gt;&amp;&gt;&gt;</tt> and
<tt>tuple&lt;Types...&gt;</tt> are not the same type. &mdash; <i>end note</i>]
</ins>
<p/>
The constructor is explicit if and only if <tt>is_convertible&lt;const U<sub><i>i</i></sub>&amp;, 
T<sub><i>i</i></sub>&gt;::value</tt> is false for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 20.4.2.1 [tuple.cnstr]/20, edit as follows:</p>

<blockquote>
<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p><tt>is_constructible&lt;T<sub><i>i</i></sub>, U<sub><i>i</i></sub>&amp;&amp;&gt;::value</tt> is true for all 
<tt><i>i</i></tt><del>.</del><ins>, and</ins></p></li>
<li><p><ins><tt>sizeof...(Types) != 1</tt>, or <tt>is_convertible&lt;tuple&lt;UTypes...&gt;&amp;&amp;,
Types...&gt;::value</tt> is false and <tt>is_constructible&lt;Types..., tuple&lt;UTypes...&gt;&amp;&amp;&gt;::value</tt>
is false.</ins></p></li>
</ul>
<p>
<ins>[<i>Note</i>: to avoid infinite template recursion in a trait-based implementation
for the case where <tt>UTypes...</tt> is a single type that has a constructor template that accepts
<tt>tuple&lt;Types...&gt;</tt>, implementations need to additionally check that
<tt>remove_cv_t&lt;remove_reference_t&lt;tuple&lt;UTypes...&gt;&amp;&amp;&gt;&gt;</tt> and
<tt>tuple&lt;Types...&gt;</tt> are not the same type. &mdash; <i>end note</i>]</ins>
<p/>
The constructor is explicit if and only if <tt>is_convertible&lt;U<sub><i>i</i></sub>&amp;&amp;, 
T<sub><i>i</i></sub>&gt;::value</tt> is false for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>

</li>

<li><p><b>Alternative 2 (do the sameness-check normatively):</b></p>

<ol>
<li><p>In 20.4.2.1 [tuple.cnstr]/17, edit as follows:</p>
<blockquote>
<pre>
template &lt;class... UTypes> <i>EXPLICIT</i> constexpr tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p><tt>is_constructible&lt;T<sub><i>i</i></sub>, const Ui&amp;&gt;::value</tt> is true for all 
<tt><i>i</i></tt><del>.</del><ins>, and</ins></p></li>
<li><p><ins><tt>sizeof...(Types) != 1</tt>, or <tt>is_convertible&lt;const tuple&lt;UTypes...&gt;&amp;,
Types...&gt;::value</tt> is false and <tt>is_constructible&lt;Types..., const tuple&lt;UTypes...&gt;&amp;&gt;::value</tt>
is false and <tt>is_same&lt;tuple&lt;Types...&gt;, remove_cv_t&lt;remove_reference_t&lt;const
tuple&lt;UTypes...&gt;&amp;&gt;&gt;&gt;::value</tt> is false.</ins></p></li>
</ul>
<p>
The constructor is explicit if and only if <tt>is_convertible&lt;const U<sub><i>i</i></sub>&amp;, 
T<sub><i>i</i></sub>&gt;::value</tt> is false for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 20.4.2.1 [tuple.cnstr]/20, edit as follows:</p>

<blockquote>
<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p><tt>is_constructible&lt;T<sub><i>i</i></sub>, U<sub><i>i</i></sub>&amp;&amp;&gt;::value</tt> is true for all 
<tt><i>i</i></tt><del>.</del><ins>, and</ins></p></li>
<li><p><ins><tt>sizeof...(Types) != 1</tt>, or <tt>is_convertible&lt;tuple&lt;UTypes...&gt;&amp;&amp;,
Types...&gt;::value</tt> is false and <tt>is_constructible&lt;Types..., tuple&lt;UTypes...&gt;&amp;&amp;&gt;::value</tt>
is false and <tt>is_same&lt;tuple&lt;Types...&gt;, 
remove_cv_t&lt;remove_reference_t&lt;tuple&lt;UTypes...&gt;&amp;&amp;&gt;&gt;&gt;::value</tt> is
false.</ins></p></li>
</ul>
<p>
The constructor is explicit if and only if <tt>is_convertible&lt;U<sub><i>i</i></sub>&amp;&amp;, 
T<sub><i>i</i></sub>&gt;::value</tt> is false for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>

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

<p><i>[2016-03, Jacksonville]</i></p>

<p>
STL provides a simplification of Ville's alternative #2 (with no semantic changes), and it's shipping in VS 2015 Update 2.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4567.</p>

<ol style="list-style-type:upper-alpha">
<li>
<p>
This approach is orthogonal to the Proposed Resolution for LWG <a href="lwg-active.html#2312">2312</a>:
</p>
<ol>
<li><p>Edit 20.4.2.1 [tuple.cnstr] as indicated:</p>
<blockquote>
<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p>
<tt>is_constructible&lt;<i>T<sub>i</sub></i>, const <i>U<sub>i</sub></i>&amp;&gt;::value</tt> is <tt>true</tt> for all
<tt><i>i</i></tt><ins>, and</ins>
</p></li>
<li><p>
<ins><tt>sizeof...(Types) != 1</tt>, or (when <tt>Types...</tt> expands to <tt>T</tt> and
<tt>UTypes...</tt> expands to <tt>U</tt>) <tt>!is_convertible_v&lt;const tuple&lt;U&gt;&amp;, T&gt; &amp;&amp;
!is_constructible_v&lt;T, const tuple&lt;U&gt;&amp;&gt; &amp;&amp; !is_same_v&lt;T, U&gt;</tt> is <tt>true</tt></ins>.
</p></li>
</ul>
<p>
The constructor is explicit if and only if <tt>is_convertible&lt;const <i>U<sub>i</sub></i>&amp;,
<i>T<sub>i</sub></i>&gt;::value</tt> is <tt>false</tt> for at least one <tt><i>i</i></tt>.
</p>
</blockquote>

<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p>
<tt>is_constructible&lt;<i>T<sub>i</sub></i>, <i>U<sub>i</sub></i>&amp;&amp;&gt;::value</tt> is <tt>true</tt> for all
<tt><i>i</i></tt><ins>, and</ins>
</p></li>
<li><p>
<ins><tt>sizeof...(Types) != 1</tt>, or (when <tt>Types...</tt> expands to <tt>T</tt> and
<tt>UTypes...</tt> expands to <tt>U</tt>) <tt>!is_convertible_v&lt;tuple&lt;U&gt;, T&gt; &amp;&amp;
!is_constructible_v&lt;T, tuple&lt;U&gt;&gt; &amp;&amp; !is_same_v&lt;T, U&gt;</tt> is <tt>true</tt></ins>.
</p></li>
</ul>
<p> 
The constructor is explicit if and only if <tt>is_convertible&lt;<i>U<sub>i</sub></i>&amp;&amp;,
<i>T<sub>i</sub></i>&gt;::value</tt> is <tt>false</tt> for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</li>

<li><p>This approach is presented as a merge with the parts of the Proposed Resolution for LWG <a href="lwg-active.html#2312">2312</a>
with overlapping modifications in the same paragraph, to provide editorial guidance if <a href="lwg-active.html#2312">2312</a> would be 
accepted.</p>

<ol>
<li><p>Edit 20.4.2.1 [tuple.cnstr] as indicated:</p>

<blockquote>
<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-17- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p>
<ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt>, and</ins>
</p></li>
<li><p>
<tt>is_constructible&lt;<i>T<sub>i</sub></i>, const <i>U<sub>i</sub></i>&amp;&gt;::value</tt> is <tt>true</tt> for all
<tt><i>i</i></tt><ins>, and</ins>
</p></li>
<li><p>
<ins><tt>sizeof...(Types) != 1</tt>, or (when <tt>Types...</tt> expands to <tt>T</tt> and
<tt>UTypes...</tt> expands to <tt>U</tt>) <tt>!is_convertible_v&lt;const tuple&lt;U&gt;&amp;, T&gt; &amp;&amp;
!is_constructible_v&lt;T, const tuple&lt;U&gt;&amp;&gt; &amp;&amp; !is_same_v&lt;T, U&gt;</tt> is <tt>true</tt></ins>.
</p></li>
</ul>
<p>
The constructor is explicit if and only if <tt>is_convertible&lt;const <i>U<sub>i</sub></i>&amp;,
<i>T<sub>i</sub></i>&gt;::value</tt> is <tt>false</tt> for at least one <tt><i>i</i></tt>.
</p>
</blockquote>

<pre>
template &lt;class... UTypes&gt; <i>EXPLICIT</i> constexpr tuple(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-20- <i>Remarks</i>: This constructor shall not participate in overload resolution unless
</p>
<ul>
<li><p>
<ins><tt>sizeof...(Types) == sizeof...(UTypes)</tt>, and</ins>
</p></li>
<li><p>
<tt>is_constructible&lt;<i>T<sub>i</sub></i>, <i>U<sub>i</sub></i>&amp;&amp;&gt;::value</tt> is <tt>true</tt> for all
<tt><i>i</i></tt><ins>, and</ins>
</p></li>
<li><p>
<ins><tt>sizeof...(Types) != 1</tt>, or (when <tt>Types...</tt> expands to <tt>T</tt> and
<tt>UTypes...</tt> expands to <tt>U</tt>) <tt>!is_convertible_v&lt;tuple&lt;U&gt;, T&gt; &amp;&amp;
!is_constructible_v&lt;T, tuple&lt;U&gt;&gt; &amp;&amp; !is_same_v&lt;T, U&gt;</tt> is <tt>true</tt></ins>.
</p></li>
</ul>
<p>
The constructor is explicit if and only if <tt>is_convertible&lt;<i>U<sub>i</sub></i>&amp;&amp;,
<i>T<sub>i</sub></i>&gt;::value</tt> is <tt>false</tt> for at least one <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>

</li>
</ol>





<hr>
<h3><a name="2550" href="#2550">2550.</a> Wording of unordered container's <tt>clear()</tt> method complexity</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Yegor Derevenets <b>Opened:</b> 2015-10-11 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.req">active issues</a> in [unord.req].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.req">issues</a> in [unord.req].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I believe, the wording of the complexity specification for the standard
unordered containers' <tt>clear()</tt> method should be changed from "Linear" to
"Linear in <tt>a.size()</tt>". As of <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4527.pdf">N4527</a>, 
the change should be done in the Complexity column of row "<tt>a.clear()</tt>..." in "Table 102 &mdash; Unordered
associative container requirements" in section Unordered associative containers 23.2.5 [unord.req].
<p/>
From the current formulation it is not very clear, whether the complexity is linear in the number of buckets, 
in the number of elements, or both. cppreference is also <a href="http://en.cppreference.com/w/cpp/container/unordered_map/clear#Complexity">not very specific</a>: 
it mentions the size of the container without being explicit about what exactly the size is.
<p/>
The issue is inspired by a <a href="https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67922">performance bug in libstdc++</a>.
The issue is related to LWG <a href="lwg-active.html#1175">1175</a>.
</p>

<p><i>[2016-03 Jacksonville]</i></p>

<p>
GR: erase(begin. end) has to touch every element. clear() has the option of working with buckets instead. will be faster in some cases, slower in some.
clear() has to be at least linear in size as it has to run destructors.<br/>
MC: wording needs to say what it's linear in, either elements or buckets.<br/>
HH: my vote is the proposed resolution is correct.<br/>
Move to Ready.<br/>
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4527.</p>

<ol>
<li><p>Change 23.2.5 [unord.req], Table 102 as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 102 &mdash; Unordered associative container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note pre-&#47;post-condition</th>
<th>Complexity</th>
</tr>

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

<tr>
<td>
<tt>a.clear()</tt>
</td>
<td>
<tt>void</tt>
</td>
<td>
Erases all elements in the<br/>
container. Post: <tt>a.empty()</tt><br/>
returns <tt>true</tt>
</td>
<td>
Linear <ins>in <tt>a.size()</tt></ins>.
</td>
</tr>

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

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2551" href="#2551">2551.</a> [fund.ts.v2] "Exception safety" cleanup in library fundamentals required</h3>
<p><b>Section:</b> 8.2.1.1 [fund.ts.v2::memory.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2015-10-24 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
Similar to LWG <a href="lwg-defects.html#2495">2495</a>, the current library fundamentals working paper refers to several "Exception safety" elements
without providing a definition for this element type.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4529.html">N4529</a>.</p>

<ol>
<li><p>Change 8.2.1.1 [memory.smartptr.shared.const] as indicated:</p>

<blockquote>
<pre>
template&lt;class Y&gt; explicit shared_ptr(Y* p);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Effects</i>: When <tt>T</tt> is not an array type, constructs a <tt>shared_ptr</tt> object that <em>owns</em> the pointer 
<tt>p</tt>. Otherwise, constructs a <tt>shared_ptr</tt> that <em>owns</em> <tt>p</tt> and a deleter of an unspecified type that 
calls <tt>delete[] p</tt>. <ins>If an exception is thrown, <tt>delete p</tt> is called when <tt>T</tt> is not an array type, 
<tt>delete[] p</tt> otherwise.</ins>
<p/>
[&hellip;]
<p/>
<del>-6- <i>Exception safety</i>: If an exception is thrown, <tt>delete p</tt> is called when <tt>T</tt> is not an array type, 
<tt>delete[] p</tt> otherwise.</del>
</p>
</blockquote>
<pre>
template&lt;class Y, class D&gt; shared_ptr(Y* p, D d);
template&lt;class Y, class D, class A&gt; shared_ptr(Y* p, D d, A a);
template &lt;class D&gt; shared_ptr(nullptr_t p, D d);
template &lt;class D, class A&gt; shared_ptr(nullptr_t p, D d, A a);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-9- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that <em>owns</em> the object <tt>p</tt> and the deleter <tt>d</tt>. 
The second and fourth constructors shall use a copy of <tt>a</tt> to allocate memory for internal use. <ins>If an exception is thrown, 
<tt>d(p)</tt> is called.</ins>
<p/>
[&hellip;]
<p/>
<del>-12- <i>Exception safety</i>: If an exception is thrown, <tt>d(p)</tt> is called.</del>
</p>
</blockquote>
<p>
[&hellip;]
</p>
<pre>
template&lt;class Y&gt; explicit shared_ptr(const weak_ptr&lt;Y&gt;&amp; r);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-28- <i>Effects</i>: Constructs a <tt>shared_ptr</tt> object that <em>shares ownership</em> with <tt>r</tt> and stores a copy of 
the pointer stored in <tt>r</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
<p/>
[&hellip;]
<p/>
<del>-31- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
</p>
</blockquote>
<pre>
template &lt;class Y, class D&gt; shared_ptr(unique_ptr&lt;Y, D&gt;&amp;&amp; r);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-34- <i>Effects</i>: Equivalent to <tt>shared_ptr(r.release(), r.get_deleter())</tt> when <tt>D</tt> is not a reference type, 
otherwise <tt>shared_ptr(r.release(), ref(r.get_deleter()))</tt>. <ins>If an exception is thrown, the constructor has no effect.</ins>
<p/>
<del>-35- <i>Exception safety</i>: If an exception is thrown, the constructor has no effect.</del>
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2555" href="#2555">2555.</a> [fund.ts.v2] No handling for over-aligned types in <tt>optional</tt></h3>
<p><b>Section:</b> 5.3 [fund.ts.v2::optional.object] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2015-11-03 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::optional.object">active issues</a> in [fund.ts.v2::optional.object].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::optional.object">issues</a> in [fund.ts.v2::optional.object].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
5.3 [optional.object] does not specify whether over-aligned types are supported. In other places where we specify 
allocation of user-supplied types, we state that "It is implementation-defined whether over-aligned types are supported (3.11)." 
(Examples: 5.3.4 [expr.new]/p1, 20.9.9.1 [allocator.members]/p5, 20.9.11 [temporary.buffer]/p1). We 
should presumably do the same thing here.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html">N4562</a>.
</p>

<ol>
<li><p>Edit 5.3 [optional.object]/p1 as follows::</p>

<blockquote>
<p>
[&hellip;] The contained value shall be allocated in a region of the <tt>optional&lt;T&gt;</tt> storage suitably aligned for 
the type <tt>T</tt>. <ins>It is implementation-defined whether over-aligned types are supported (C++14 &sect;3.11).</ins> 
When an object of type <tt>optional&lt;T&gt;</tt> is contextually converted to <tt>bool</tt>, the conversion returns 
<tt>true</tt> if the object contains a value; otherwise the conversion returns <tt>false</tt>. 
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2573" href="#2573">2573.</a> [fund.ts.v2] <tt>std::hash&lt;std::experimental::shared_ptr&lt;T&gt;&gt;</tt> does not work for arrays</h3>
<p><b>Section:</b> 8.2.1 [fund.ts.v2::memory.smartptr.shared] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-13 <b>Last modified:</b> 2016-03-06</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
The library fundamentals TS does not provide a separate specification for <tt>std::hash&lt;std::experimental::shared_ptr&lt;T&gt;&gt;</tt>, 
deferring to the C++14 specification in &sect;20.8.2.7/3:
</p>
<blockquote>
<pre>
template &lt;class T&gt; struct hash&lt;shared_ptr&lt;T&gt; &gt;;
</pre>
<blockquote>
<p>
-3- The template specialization shall meet the requirements of class template <tt>hash</tt> (20.9.13). For an object <tt>p</tt> 
of type <tt>shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;shared_ptr&lt;T&gt; &gt;()(p)</tt> shall evaluate to the same value as
<tt>hash&lt;T*&gt;()(p.get())</tt>.
</p>
</blockquote>
</blockquote>
<p>
That specification doesn't work if <tt>T</tt> is an array type (<tt>U[N]</tt> or <tt>U[]</tt>), as in this case <tt>get()</tt> 
returns <tt>U*</tt>, which cannot be hashed by <tt>std::hash&lt;T*&gt;</tt>.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html">N4562</a>.
</p>

<ol>
<li><p>Insert a new subclause after 8.2.1.3 [memory.smartptr.shared.cast]:</p>
<blockquote class="note">
<p>
[<i>Note for the editor</i>: The synopses in [header.memory.synop] and [memory.smartptr.shared] should be updated to refer 
to the new subclause rather than C++14 &sect;20.8.2.7]
</p>
</blockquote>

<blockquote>
<p><ins>?.?.?.? <tt>shared_ptr</tt> hash support [memory.smartptr.shared.hash]</ins></p>
<pre>
<ins>template &lt;class T&gt; struct hash&lt;experimental::shared_ptr&lt;T&gt;&gt;;</ins>
</pre>
<blockquote>
<p>
<ins>-1- The template specialization shall meet the requirements of class template <tt>hash</tt> (C++14 &sect;20.9.12). 
For an object <tt>p</tt> of type <tt>experimental::shared_ptr&lt;T&gt;</tt>, <tt>hash&lt;experimental::shared_ptr&lt;T&gt;&gt;()(p)</tt> 
shall evaluate to the same value as <tt>hash&lt;typename experimental::shared_ptr&lt;T&gt;::element_type*&gt;()(p.get())</tt>.</ins>
</p>
</blockquote>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2596" href="#2596">2596.</a> <tt>vector::data()</tt> should use <tt>addressof</tt></h3>
<p><b>Section:</b> 23.3.11.4 [vector.data] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-02-29 <b>Last modified:</b> 2016-04-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.data">issues</a> in [vector.data].</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 23.3.11.4 [vector.data], we have:
</p>
<blockquote>
<p>
<i>Returns</i>: A pointer such that <tt>[data(),data() + size())</tt> is a valid range. For a non-empty vector, 
<tt>data() == &amp;front()</tt>.
</p>
</blockquote>
<p>
This should be:
</p>
<blockquote>
<p>
<i>Returns</i>: A pointer such that <tt>[data(),data() + size())</tt> is a valid range. For a non-empty vector, 
<tt>data() == addressof(front())</tt>.
</p>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<ol>
<li><p>Change 23.3.11.4 [vector.data] p1 as indicated:</p>

<blockquote>
<pre>
T* data() noexcept;
const T* data() const noexcept;
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: A pointer such that <tt>[data(), data() + size())</tt> is a valid range. For a non-empty vector,
<tt>data() == <ins>addressof(</ins><del>&amp;</del>front()<ins>)</ins></tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2667" href="#2667">2667.</a> <code>path::root_directory()</code> description is confusing</h3>
<p><b>Section:</b> 27.10.8.4.9 [path.decompose] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-07-03 <b>Last modified:</b> 2016-04-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.10.8.4.9 [path.decompose] p5 says:</p>
  <blockquote>
    <p>If <i>root-directory</i> is composed of <i>slash name</i>, <i>slash</i> is excluded from the returned string.</p>
  </blockquote>
<p>but the grammar says that <i>root-directory</i> is just slash so that makes no sense.</p>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 




<p><b>Proposed resolution:</b></p>
<p>
  <i>Change 27.10.8.4.9 [path.decompose] as indicated:</i>
</p>
  
  <blockquote>
    <pre>path root_directory() const;</pre>
    <blockquote>
      <p>
        <i>Returns:</i> <i>root-directory</i>, if <code>pathname</code> includes <i>root-directory</i>, otherwise <code>path()</code>.
      </p>
      <p><del>If <i>root-directory</i> is composed of <i>slash name</i>, <i>slash</i> is excluded from the returned string.</del></p>
    </blockquote>
  </blockquote>





<hr>
<h3><a name="2669" href="#2669">2669.</a> <code>recursive_directory_iterator</code> effects refers to non-existent functions
</h3>
<p><b>Section:</b> 27.10.14.1 [rec.dir.itr.members] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-07-10 <b>Last modified:</b> 2016-04-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#rec.dir.itr.members">active issues</a> in [rec.dir.itr.members].</p>
<p><b>View all other</b> <a href="lwg-index.html#rec.dir.itr.members">issues</a> in [rec.dir.itr.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 align="left">
  <code>operator++/increment</code>, second bullet item, &para;39 says
    "Otherwise if <code>
  recursion_pending() &amp;&amp; is_directory(this-&gt;status())  
  &amp;&amp; (!is_symlink(this-&gt;symlink_status())</code>..."
  but <code>recursive_directory_iterator</code> does not have <code>status</code>
  or <code>symlink_status</code> members.
</p>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 



<p><b>Proposed resolution:</b></p>
  <p>
  <i>Change 27.10.14.1 [rec.dir.itr.members] &para;39 as indicated:</i></p>
  <blockquote>
    <p align="left">Otherwise if <code>
      recursion_pending() &amp;&amp; is_directory(<ins>(*</ins>this<ins>)</ins>-&gt;status())
      &amp;&amp; (!is_symlink(<ins>(*</ins>this<ins>)</ins>-&gt;symlink_status())
    </code>..."</p>

  </blockquote>
  





<hr>
<h3><a name="2670" href="#2670">2670.</a> <code>system_complete</code> refers to undefined variable 'base'
</h3>
<p><b>Section:</b> 27.10.15.36 [fs.op.system_complete] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-07-20 <b>Last modified:</b> 2016-04-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>The example says "...or <code>p</code> and <code>base</code> have the same <code>root_name()</code>.", but
<code>base</code> is not defined. I believe it refers to the value returned by <code>current_path()</code>.
</p>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 



<p><b>Proposed resolution:</b></p>
<p>
  <i>Change 27.10.15.36 [fs.op.system_complete] as indicated:</i>
</p>
  <blockquote>
    <p>For Windows based operating systems, <code>system_complete(p)</code> has the same semantics as
    <code>absolute(p, current_path())</code> if <code>p.is_absolute() || !p.has_root_name()</code>
    or <code>p</code> and <code><del>base</del> <ins>current_path()</ins></code>
    have the same <code>root_name()</code>. Otherwise it acts like <code>absolute(p, cwd)</code> is the current
    directory for the <code>p.root_name()</code> drive. This will be the current directory for that drive
    the last time it was set, and thus may be residue left over from a prior program run by the
    command processor. Although these semantics are useful, they may be surprising.</p>
  </blockquote>





<hr>
<h3><a name="2671" href="#2671">2671.</a> Errors in Copy</h3>
<p><b>Section:</b> 27.10.15.3 [fs.op.copy] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-07-28 <b>Last modified:</b> 2016-04-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.op.copy">active issues</a> in [fs.op.copy].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.copy">issues</a> in [fs.op.copy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
  <p>27.10.15.3 [fs.op.copy] paragraph 16 says:</p>
  <blockquote>
    <p>
      Otherwise if <code>!exists(t) &amp; (options &amp;
        copy_options::copy_symlinks) != 
        copy_options::none</code>, then <code>copy_symlink(from, to, options)</code>.
    </p>
  </blockquote>
  <p>But there is no overload of <code>copy_symlink</code> that takes a <code>copy_options</code>;
  it should be <code>copy_symlink(from, to)</code>.</p>

  <p>27.10.15.3 [fs.op.copy] Paragraph 26 says:</p>
  <blockquote>
    <p>as if by <code>for (directory_entry& x : directory_iterator(from))</code></p>
  </blockquote>
  <p>but the result of dereferencing a <code>directory_iterator</code> is const; it should be:</p>
  <blockquote>
    <p>as if by <code>for (<ins>const </ins>directory_entry& x : directory_iterator(from))</code></p>
  </blockquote>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 



<p><b>Proposed resolution:</b></p>
  <p>Change 27.10.15.3 [fs.op.copy] paragraph 16 as indicated:</p>
  <blockquote>
    <p>
      Otherwise if <code>
        !exists(t) &amp; (options &amp;
        copy_options::copy_symlinks) !=
        copy_options::none
      </code>, then <code>copy_symlink(from, to<del>, options</del>)</code>.
    </p>
  </blockquote>
  <p>Change 27.10.15.3 [fs.op.copy] paragraph 26 as indicated:</p>
  <blockquote>
    <p>
      as if by <code>
        for (<ins>const </ins>directory_entry& x : directory_iterator(from))
      </code>
    </p>
  </blockquote>





<hr>
<h3><a name="2673" href="#2673">2673.</a> <code>status()</code> effects cannot be implemented as specified</h3>
<p><b>Section:</b> 27.10.15.33 [fs.op.status] <b>Status:</b> <a href="lwg-active.html#Ready">Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-09-15 <b>Last modified:</b> 2016-04-14</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Ready">Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>27.10.15.33 [fs.op.status] paragraph 2 says:</p>
<blockquote>
<p><i>Effects:</i> As if:</p>
<pre>error_code ec;
file_status result = status(p, ec);
if (result == file_type::none)
...</pre>
</blockquote>
<p>This won't compile, there is no comparison operator for <code>file_status</code> and <code>file_type</code>,
and the conversion from <code>file_type</code> to <code>file_status</code> is explicit.</p>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 



<p><b>Proposed resolution:</b></p>
<p>Change 27.10.15.33 [fs.op.status] paragraph 2:</p>
<blockquote>
<p><i>Effects:</i> As if:</p>
<pre>error_code ec;
file_status result = status(p, ec);
if (result<ins>.type()</ins> == file_type::none)
...</pre>
</blockquote>





<hr>
<h3><a name="2674" href="#2674">2674.</a> Bidirectional iterator requirement on <code>path::iterator</code>
is very expensive</h3>
<p><b>Section:</b> 27.10.8.5 [path.itr] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-09-15 <b>Last modified:</b> 2016-05-17</p>
<p><b>Priority: </b>2
</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>
27.10.8.5 [path.itr] requires <tt>path::iterator</tt> to be a BidirectionalIterator, which also implies
the ForwardIterator requirement in [forward.iterators] p6 for the following assertion
to pass:
</p>
<blockquote>
<pre>
path p("/");
auto it1 = p.begin();
auto it2 = p.begin();
assert( &amp;*it1 == &amp;*it2 );
</pre>
</blockquote>
<p>This prevents iterators containing a <code>path</code>, or constructing one on the fly when
dereferenced, the object they point to must exist outside the iterators and potentially
outlive them. The only practical way to meet the requirement is for <code>p</code> to hold
a container of child <code>path</code> objects so the iterators can refer to those
children. This makes a <code>path</code> object much larger than would naïvely be
expected.</p>
<p>The Boost and MSVC implementations of Filesystem fail to meet this requirement. The
GCC implementation meets it, but it makes <code>sizeof(path) == 64</code> (for 64-bit) or
<code>sizeof(path) == 40</code> for 32-bit, and makes many path operations
more expensive.</p>

<p><i>[21 Nov 2015 Beman comments:]</i></p>

<p>
The ForwardIterator requirement in
[forward.iterators] "If <tt>a</tt> and <tt>b</tt> are both dereferenceable, then <tt>a == b</tt> if and only if 
<tt>*a</tt> and <tt>*b</tt> are bound to the same object." will be removed by N4560, Working Draft, C++ Extensions for
Ranges. I see no point in requiring something for the File System TS that is expensive,
has never to my knowledge been requested by users, and is going to go away soon anyhow.
The wording I propose below removes the requirement.
</p>

<p><i>[<b>Apr 2016 Issue updated to address the C++ Working Paper. Previously addressed File System TS</b>]</i></p>
 



<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<ol>
<li>
<p>Change 27.10.8.5 [path.itr] paragraph 2:</p>
<blockquote>
<p>A <code>path::iterator</code> is a constant iterator satisfying all the requirements of a bidirectional iterator 
(C++14 §24.1.4 Bidirectional iterators) <ins>except that there is no requirement
that two equal iterators be bound to the same object</ins>. Its <code>value_type</code> is <code>path</code>.</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2683" href="#2683">2683.</a> <code>filesystem::copy()</code> says "no effects"</h3>
<p><b>Section:</b> 27.10.15.3 [fs.op.copy] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-04-19 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fs.op.copy">active issues</a> in [fs.op.copy].</p>
<p><b>View all other</b> <a href="lwg-index.html#fs.op.copy">issues</a> in [fs.op.copy].</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 27.10.15.3 [fs.op.copy]/8 the final bullet says "Otherwise, no effects" which
implies there is no call to <code>ec.clear()</code> if nothing happens, nor any
error condition, is that right?
</p>


<p><b>Proposed resolution:</b></p>
<p>Change 27.10.15.3 [fs.op.copy]/8 as indicated:</p>
<blockquote><del>Otherwise no effects.</del> <ins>For the signature with argument <code>ec</code>, <code>ec.clear()</code>.</ins> 
</blockquote>





<hr>
<h3><a name="2684" href="#2684">2684.</a> priority_queue lacking comparator typedef</h3>
<p><b>Section:</b> 23.6.5 [priority.queue] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Robert Haberlach <b>Opened:</b> 2016-05-02 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#priority.queue">issues</a> in [priority.queue].</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 containers that take a comparison functor (<tt>set</tt>, <tt>multiset</tt>,
<tt>map</tt>, and <tt>multimap</tt>) have a typedef for the comparison functor.  
<tt>priority_queue</tt> does not.
</p>


<p><b>Proposed resolution:</b></p>
<p>Augment [priority.queue] as indicated:</p>

<p>
<pre>
 typedef Container container_type;
 <ins>typedef Compare value_compare;</ins>
</pre>
</p>





<hr>
<h3><a name="2685" href="#2685">2685.</a> <tt>shared_ptr</tt> deleters must not not throw on move construction</h3>
<p><b>Section:</b> 20.10.2.2.1 [util.smartptr.shared.const] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-05-03 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.const">issues</a> in [util.smartptr.shared.const].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>In 20.10.2.2.1 [util.smartptr.shared.const] p8 the <tt>shared_ptr</tt> constructors taking
a deleter say:</p>

<blockquote><p>The copy constructor and destructor of <tt>D</tt> shall not throw exceptions.</p></blockquote>

<p>It's been pointed out that this doesn't forbid throwing moves, which
makes it difficult to avoid a leak here:</p>

<p><pre>
struct D {
  D() = default;
  D(const D&) noexcept = default;
  D(D&&) { throw 1; }
  void operator()(int* p) const { delete p; }
};

shared_ptr&lt;int&gt; p{new int, D{}};
</pre></p>

<p>"The copy constructor" should be changed to reflect that the chosen
constructor might not be a copy constructor, and that copies made
using any constructor must not throw.</p>

<p>N.B. the same wording is used for the allocator argument, but that's
redundant because the <tt>Allocator</tt> requirements already forbid exceptions
when copying or moving.
</p>


<p><b>Proposed resolution:</b></p>
<p>
[Drafting note: the relevant expressions we're concerned about are
enumerated in the <tt>CopyConstructible</tt> and <tt>MoveConstructible</tt>
requirements, so I see no need to repeat them by saying something
clunky like "Initialization of an object of type <tt>D</tt> from an expression
of type (possibly const) <tt>D</tt> shall not throw exceptions", we can just
refer to them. An alternative would be to define
<tt>NothrowCopyConstructible</tt>, which includes <tt>CopyConstructible</tt> but
requires that construction and destruction do not throw.]
</p>

<p>
Change 20.10.2.2.1 [util.smartptr.shared.const] p8:
</p>

<blockquote>
<p>
<tt>D</tt> shall be <tt>CopyConstructible</tt> <ins>and such construction shall not
throw exceptions.</ins> The <del>copy constructor and</del> destructor
of <tt>D</tt> shall not throw exceptions.
</p>
</blockquote>






<hr>
<h3><a name="2688" href="#2688">2688.</a> <tt>clamp</tt> misses preconditions and has extraneous condition on result</h3>
<p><b>Section:</b> 25.5.8 [alg.clamp] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Martin Moene <b>Opened:</b> 2016-03-23 <b>Last modified:</b> 2016-05-22</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 Jacksonville (2016), <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0025r0.html">P0025R0</a> was 
voted in instead of the intended <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0025r1.html">P0025R1</a>. 
This report contains the necessary mending along with two other improvements.
<p/>
This report:
</p>
<ul>
<li><p>adds the precondition that misses from P0025R0 but is in P0025R1,</p></li>
<li><p>corrects the returns: specification that contains an extraneous condition,</p></li>
<li><p>replaces the now superfluous remark with a note on usage of clamp with <tt>float</tt> or <tt>double</tt>.</p></li>
</ul>
<p>
Thanks to Carlo Assink and David Gaarenstroom for making us aware of the extraneous condition in the returns: 
specification and for suggesting the fix and to Jeffrey Yasskin for suggesting to add a note like p3.
</p>

<p><i>[2016-05 Issues Telecom]</i></p>

<p>
Reworded p3 slightly.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li><p>Edit 25.5.8 [alg.clamp] as indicated:</p>

<blockquote><pre>
template&lt;class T&gt;
  constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi);
template&lt;class T, class Compare&gt;
  constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi, Compare comp);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: <ins>The value of <tt>lo</tt> shall be no greater than <tt>hi</tt>.</ins> For the first form, 
type <tt>T</tt> shall be <tt>LessThanComparable</tt> (Table 18).
<p/>
-2- <i>Returns</i>: <ins><tt>lo</tt> if <tt>v</tt> is less than <tt>lo</tt>, <tt>hi</tt> if <tt>hi</tt> is less than 
<tt>v</tt>, otherwise <tt>v</tt></ins><del>The larger value of <tt>v</tt> and <tt>lo</tt> if <tt>v</tt> is smaller than 
<tt>hi</tt>, otherwise the smaller value of <tt>v</tt> and <tt>hi</tt></del>.
<p/>
-3- <i><ins>Note</ins><del>Remarks</del></i>: <ins>If NaN is avoided, <tt>T</tt> can be <tt>float</tt> or 
<tt>double</tt></ins><del>Returns the first argument when it is equivalent to one of the boundary arguments</del>.
<p/>
-4- <i>Complexity</i>: At most two comparisons.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<ol>
<li><p>Edit 25.5.8 [alg.clamp] as indicated:</p>

<blockquote><pre>
template&lt;class T&gt;
  constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi);
template&lt;class T, class Compare&gt;
  constexpr const T&amp; clamp(const T&amp; v, const T&amp; lo, const T&amp; hi, Compare comp);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: <ins>The value of <tt>lo</tt> shall be no greater than <tt>hi</tt>.</ins> For the first form, 
type <tt>T</tt> shall be <tt>LessThanComparable</tt> (Table 18).
<p/>
-2- <i>Returns</i>: <ins><tt>lo</tt> if <tt>v</tt> is less than <tt>lo</tt>, <tt>hi</tt> if <tt>hi</tt> is less than 
<tt>v</tt>, otherwise <tt>v</tt></ins><del>The larger value of <tt>v</tt> and <tt>lo</tt> if <tt>v</tt> is smaller than 
<tt>hi</tt>, otherwise the smaller value of <tt>v</tt> and <tt>hi</tt></del>.
<p/>
-3- <i><ins>Note</ins><del>Remarks</del></i>: <ins>If NaN is avoided, <tt>T</tt> can be a floating point type</ins>
<del>Returns the first argument when it is equivalent to one of the boundary arguments</del>.
<p/>
-4- <i>Complexity</i>: At most two comparisons.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2689" href="#2689">2689.</a> Parallel versions of <tt>std::copy</tt> and <tt>std::move</tt> shouldn't be in order</h3>
<p><b>Section:</b> 25.4.1 [alg.copy], 25.4.2 [alg.move] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-03-23 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#alg.copy">active issues</a> in [alg.copy].</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.copy">issues</a> in [alg.copy].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
25.2.5 [algorithms.parallel.overloads]/2 says that "Unless otherwise specified, the semantics of 
<tt>ExecutionPolicy</tt> algorithm overloads are identical to their overloads without."
<p/>
There's no "otherwise specified" for the <tt>ExecutionPolicy</tt> overloads for <tt>std::copy</tt> and <tt>std::move</tt>, 
so the requirement that they "start[] from first and proceed[] to last" in the original algorithm's description would 
seem to apply, which defeats the whole point of adding a parallel overload.
</p>

<p><i>[2016-05 Issues Telecom]</i></p>

<p>
Marshall noted that all three versions of copy have subtly different wording, and suggested that they should not.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Insert the following paragraphs after 25.4.1 [alg.copy]/4:</p>

<blockquote><pre>
<ins>template&lt;class ExecutionPolicy, class InputIterator, class OutputIterator&gt;
  OutputIterator copy(ExecutionPolicy&amp;&amp; policy, InputIterator first, InputIterator last,
                      OutputIterator result);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: The ranges <tt>[first, last)</tt> and <tt>[result, result + (last - first))</tt> shall not 
overlap.</ins>
<p/>
<ins>-?- <i>Effects</i>: Copies elements in the range <tt>[first, last)</tt> into the range <tt>[result, result + (last -
first))</tt>. For each non-negative integer <tt>n &lt; (last - first)</tt>, performs <tt>*(result + n) = *(first + n)</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>result + (last - first)</tt>.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Exactly <tt>last - first</tt> assignments.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Insert the following paragraphs after 25.4.2 [alg.move]/4:</p>

<blockquote><pre>
<ins>template&lt;class ExecutionPolicy, class InputIterator, class OutputIterator&gt;
  OutputIterator move(ExecutionPolicy&amp;&amp; policy, InputIterator first, InputIterator last,
                      OutputIterator result);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires</i>: The ranges <tt>[first, last)</tt> and <tt>[result, result + (last - first))</tt> shall not 
overlap.</ins>
<p/>
<ins>-?- <i>Effects</i>: Moves elements in the range <tt>[first, last)</tt> into the range <tt>[result, result + (last -
first))</tt>. For each non-negative integer <tt>n &lt; (last - first)</tt>, performs 
<tt>*(result + n) = std::move(*(first + n))</tt>.</ins>
<p/>
<ins>-?- <i>Returns</i>: <tt>result + (last - first)</tt>.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Exactly <tt>last - first</tt> assignments.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2698" href="#2698">2698.</a> Effect of <tt>assign()</tt> on iterators/pointers/references</h3>
<p><b>Section:</b> 23.2.3 [sequence.reqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-04-25 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#sequence.reqmts">active issues</a> in [sequence.reqmts].</p>
<p><b>View all other</b> <a href="lwg-index.html#sequence.reqmts">issues</a> in [sequence.reqmts].</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 sequence container requirements table says nothing about the effect of <tt>assign()</tt> on iterators, 
pointers or references into the container. Before LWG <a href="lwg-defects.html#2209">2209</a> (and LWG <a href="lwg-defects.html#320">320</a> for <tt>std::list</tt>), 
<tt>assign()</tt> was specified as "erase everything then <tt>insert</tt>", which implies wholesale invalidation from the 
"erase everything" part. With that gone, the blanket "no invalidation" wording in 
23.2.1 [container.requirements.general]/12 would seem to apply, which makes absolutely no sense.
<p/>
The proposed wording below simply spells out the invalidation rule implied by the previous "erase everything" wording.
</p>

<p><i>[2016-05 Issues Telecom]</i></p>

<p>
This is related to <a href="lwg-active.html#2256">2256</a>
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>In 23.2.3 [sequence.reqmts], edit Table 107 (Sequence container requirements) as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 107 &mdash; Sequence container requirements (in addition to container)</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>a.assign(i, j)</tt>
</td>
<td><tt>void</tt></td>
<td>
<i>Requires</i>: <tt>T</tt> shall be <tt>EmplaceConstructible</tt> into <tt>X</tt> from <tt>*i</tt> and assignable from 
<tt>*i</tt>.<br/>For <tt>vector</tt>, if the iterator does not meet the forward iterator requirements (24.2.5),<br/> 
<tt>T</tt> shall also be <tt>MoveInsertable</tt> into <tt>X</tt>.<br/> Each iterator in the range <tt>[i, j)</tt> shall be 
dereferenced exactly once. <br/>pre: <tt>i</tt>, <tt>j</tt> are not iterators into <tt>a</tt>.<br/> Replaces elements 
in <tt>a</tt> with a copy of <tt>[i, j)</tt>.<ins><br/>Invalidates all references, pointers and iterators referring to the 
elements of <tt>a</tt>.<br/>For <tt>vector</tt> and <tt>deque</tt>, also invalidates the past-the-end iterator.</ins>
</td>
</tr>
<tr>
<td colspan="3" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>
<tt>a.assign(n, t)</tt>
</td>
<td><tt>void</tt></td>
<td>
<i>Requires</i>: <tt>T</tt> shall be <tt>CopyInsertable</tt> into <tt>X</tt> and <tt>CopyAssignable</tt>.<br/>
pre: <tt>t</tt> is not a reference into <tt>a</tt>.<br/> Replaces elements in <tt>a</tt> with <tt>n</tt> 
copies of <tt>t</tt>.<ins><br/>Invalidates all references, pointers and iterators referring to the elements of 
<tt>a</tt>.<br/>
For <tt>vector</tt> and <tt>deque</tt>, also invalidates the past-the-end iterator.</ins>
</td>
</tr>
</table>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2706" href="#2706">2706.</a> Error reporting for <tt>recursive_directory_iterator::pop()</tt> is under-specified</h3>
<p><b>Section:</b> 27.10.14 [class.rec.dir.itr] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-05-09 <b>Last modified:</b> 2016-05-22</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>
Unlike <tt>increment</tt>, <tt>pop()</tt> does not specify how it reports errors nor does it provide a 
<tt>std::error_code</tt> overload. However implementing <tt>pop()</tt> all but requires performing an increment, 
so it should handle errors in the same way.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<ol>
<li><p>Change 27.10.14 [class.rec.dir.itr], class <tt>recursive_directory_iterator</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::filesystem {
  class recursive_directory_iterator {
  public:
    [&hellip;]
    void pop();
    <ins>void pop(error_code&amp; ec);</ins>
    void disable_recursion_pending();
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li><p>Change 27.10.14.1 [rec.dir.itr.members] as indicated:</p>

<blockquote>
<pre>
void pop();
<ins>void pop(error_code&amp; ec);</ins>
</pre>
<blockquote>
<p>
-30- <i>Requires</i>: <tt>*this != recursive_directory_iterator()</tt>.
<p/>
-31- <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/>
<ins>-?- <i>Throws</i>: As specified in Error reporting (27.5.6.5 [error.reporting]).</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2707" href="#2707">2707.</a> <tt>path</tt> construction and assignment should have "<tt>string_type&amp;&amp;</tt>" overloads</h3>
<p><b>Section:</b> 27.10.8 [class.path] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-05-09 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#class.path">active issues</a> in [class.path].</p>
<p><b>View all other</b> <a href="lwg-index.html#class.path">issues</a> in [class.path].</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 construction of a <tt>path</tt> from the native <tt>string_type</tt> always performs a copy, even when 
that string is passed as a rvalue. This is a large pessimization as paths are commonly constructed from temporary strings.
<p/>
One pattern I frequently see is:
</p>
<blockquote><pre>
path foo(path const&amp; p) {
  auto s = p.native();
  mutateString(s);
  return s;
}
</pre></blockquote>
<p>
Implementations should be allowed to move from <tt>s</tt> and avoid an unnecessary allocation.
I believe <tt>string_type&amp;&amp;</tt> constructor and assignment operator overloads should be added to support this.
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<ol>
<li><p>Change 27.10.8 [class.path], class <tt>path</tt> synopsis, as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: Making the <tt>string_type&amp;&amp;</tt> constructors and assignment operators <tt>noexcept</tt> 
would over-constrain implementations which may need to perform construct additional state]
</p>
</blockquote>

<blockquote>
<pre>
namespace std::filesystem {
  class path {
  public:
    [&hellip;]
    <i>// 27.10.8.4.1, constructors and destructor</i>
    path() noexcept;
    path(const path&amp; p);
    path(path&amp;&amp; p) noexcept;
    <ins>path(string_type&amp;&amp; source);</ins>
    template &lt;class Source&gt;
    path(const Source&amp; source);
    [&hellip;]
    
    <i>// 27.10.8.4.2, assignments</i>
    path&amp; operator=(const path&amp; p);
    path&amp; operator=(path&amp;&amp; p) noexcept;
    <ins>path&amp; operator=(string_type&amp;&amp; source);
    path&amp; assign(string_type&amp;&amp; source);</ins>
    template &lt;class Source&gt;
    path&amp; operator=(const Source&amp; source);
    template &lt;class Source&gt;
    path&amp; assign(const Source&amp; source)
    template &lt;class InputIterator&gt;
    path&amp; assign(InputIterator first, InputIterator last);    
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li><p>Add a new paragraph following 27.10.8.4.1 [path.construct]/3:</p>

<blockquote>
<pre>
<ins>path(string_type&amp;&amp; source);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Constructs an object of class <tt>path</tt> with <tt>pathname</tt> having the original value of 
<tt>source</tt>. <tt>source</tt> is left in a valid but unspecified state.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Add a new paragraph following 27.10.8.4.2 [path.assign]/4:</p>

<blockquote>
<pre>
<ins>path&amp; operator=(string_type&amp;&amp; source);
path&amp; assign(string_type&amp;&amp; source);</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Modifies <tt>pathname</tt> to have the original value of <tt>source</tt>. <tt>source</tt> 
is left in a valid but unspecified state.</ins>
<p/>
<ins>-?- <i>Returns</i>:<tt>*this</tt></ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2710" href="#2710">2710.</a> "<i>Effects:</i> Equivalent to ..." doesn't count "<i>Synchronization:</i>" as determined semantics</h3>
<p><b>Section:</b> 17.5.1.4 [structure.specifications] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Kazutoshi Satoda <b>Opened:</b> 2016-05-08 <b>Last modified:</b> 2016-05-22</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#structure.specifications">active issues</a> in [structure.specifications].</p>
<p><b>View all other</b> <a href="lwg-index.html#structure.specifications">issues</a> in [structure.specifications].</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>
From N4582 17.5.1.4 [structure.specifications] p3 and p4
</p>
<blockquote>
<p>
-3- Descriptions of function semantics contain the following elements (as appropriate):
</p>
<ul>
<li><i>Requires</i>: the preconditions for calling the function</li>
<li><i>Effects</i>: the actions performed by the function</li>
<li><i>Synchronization</i>: the synchronization operations (1.10) applicable to the function</li>
<li><i>Postconditions</i>: the observable results established by the function</li>
<li><i>Returns</i>: a description of the value(s) returned by the function</li>
<li><i>Throws</i>: any exceptions thrown by the function, and the conditions that would cause the exception</li>
<li><i>Complexity</i>: the time and/or space complexity of the function</li>
<li><i>Remarks</i>: additional semantic constraints on the function</li>
<li><i>Error conditions</i>: the error conditions for error codes reported by the function.</li>
<li><i>Notes</i>: non-normative comments about the function</li>
</ul>
<p>
-4- Whenever the <i>Effects:</i> element specifies that the semantics of some function <tt>F</tt> are 
<em>Equivalent to</em> some code sequence, then the various elements are interpreted as follows. If 
<tt>F</tt>'s semantics specifies a <i>Requires:</i> element, then that requirement is logically imposed prior 
to the <em>equivalent-to</em> semantics. Next, the semantics of the code sequence are determined by the 
<i>Requires:</i>, <i>Effects:</i>, <i>Postconditions:</i>, <i>Returns:</i>, <i>Throws:</i>, <i>Complexity:</i>,
<i>Remarks:</i>, <i>Error conditions:</i>, and <i>Notes:</i> specified for the function invocations contained 
in the code sequence. The value returned from <tt>F</tt> is specified by <tt>F</tt>'s <i>Returns:</i> element, 
or if <tt>F</tt> has no <i>Returns:</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified by the 
<i>Returns:</i> elements in the code sequence. If <tt>F</tt>'s semantics contains a <i>Throws:</i>,
<i>Postconditions:</i>, or <i>Complexity:</i> element, then that supersedes any occurrences of that element in the code
sequence.
</p>
</blockquote>
<p>
The third sentence of p4 says "the semantics of the code sequence are determined
by ..." and lists all elements in p3 except "<i>Synchronization:</i>".
<p/>
I think it was just an oversight because p4 was added by library issue
<a href="lwg-defects.html#997">997</a>, and its proposed resolution was drafted at the time (2009) before
"<i>Synchronization:</i>" was added into p3 for C++11.
<p/>
However, I'm not definitely sure that it is really intended and safe to
just supply "<i>Synchronization:</i>" in the list. (Could a library designer
rely on this in writing new specifications, or could someone rely on
this in writing user codes, after some years after C++11?)
</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>

<ol>
<li><p>Change 17.5.1.4 [structure.specifications] as indicated:</p>

<blockquote>
<p>
-4- Whenever the <i>Effects:</i> element specifies that the semantics of some function <tt>F</tt> are 
<em>Equivalent to</em> some code sequence, then the various elements are interpreted as follows. If 
<tt>F</tt>'s semantics specifies a <i>Requires:</i> element, then that requirement is logically imposed prior 
to the <em>equivalent-to</em> semantics. Next, the semantics of the code sequence are determined by the 
<i>Requires:</i>, <i>Effects:</i><ins>, <i>Synchronization:</i></ins>, <i>Postconditions:</i>, <i>Returns:</i>, 
<i>Throws:</i>, <i>Complexity:</i>,
<i>Remarks:</i>, <i>Error conditions:</i>, and <i>Notes:</i> specified for the function invocations contained 
in the code sequence. The value returned from <tt>F</tt> is specified by <tt>F</tt>'s <i>Returns:</i> element, 
or if <tt>F</tt> has no <i>Returns:</i> element, a non-<tt>void</tt> return from <tt>F</tt> is specified by the 
<i>Returns:</i> elements in the code sequence. If <tt>F</tt>'s semantics contains a <i>Throws:</i>,
<i>Postconditions:</i>, or <i>Complexity:</i> element, then that supersedes any occurrences of that element in the code
sequence.
</p>
</blockquote>
</li>
</ol>





</body>
</html>
