<!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 Issaquah</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 Issaquah</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P0165R3</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2016-10-17 at 04:10:06 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="2062" href="#2062">2062.</a> Effect contradictions w&#47;o no-throw guarantee of <tt>std::function</tt> swaps</h3>
<p><b>Section:</b> 20.14.12.2 [func.wrap.func], 20.14.12.2.2 [func.wrap.func.mod] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2011-05-28 <b>Last modified:</b> 2016-08-08</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Howard Hinnant observed in reflector message c++std-lib-30841 that 20.14.12.2 [func.wrap.func] 
makes the member swap <tt>noexcept</tt>, even though the non-member swap is not <tt>noexcept</tt>. 
<p/>
The latter was an outcome of the discussions during the Batavia meeting and the Madrid meeting 
involving LWG <a href="lwg-defects.html#1349">1349</a>, which seems to indicate that the remaining <tt>noexcept</tt> 
specifier at the member swap is incorrect and should be removed.
<p/>
But if we allow for a potentially throwing member swap of <tt>std::function</tt>, this causes 
another conflict with the exception specification for the following member function:
</p>
<blockquote><pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt; f) <span style="color:#C80000;font-weight:bolder">noexcept</span>;
</pre><blockquote><p>
<i>Effects</i>: <tt>function(f).<span style="color:#C80000;font-weight:bolder">swap</span>(*this);</tt>
</p>
</blockquote></blockquote>
<p>
Note that in this example the sub-expression <tt>function(f)</tt> does not cause any problems,
because of the nothrow-guarantee given in 20.14.12.2.1 [func.wrap.func.con] p. 10. The problem
is located in the usage of the swap which could potentially throw given the general latitude. 
<p/>
So, either the Madrid meeting decision need to be revised (and both member and free swap of 
<tt>std::function</tt> should be noexcept), or this function needs to be adapted as well,
e.g. by taking the exception-specification away or by changing the semantics.
<p/>
One argument for "swap-may-throw" would be to allow for small-object optimization techniques
where the copy of the target may throw. But given the fact that the swap function has been guaranteed 
to be "Throws: Nothing" from TR1 on, it seems to me that that there would still be opportunities to 
perform small-object optimizations just restricted to the set of target copies that cannot throw. 
<p/>
In my opinion member swap of <tt>std::function</tt> has always been intended to be no-throw, because
otherwise there would be no good technical reason to specify the effects of several member 
functions in terms of the "construct-swap" idiom (There are three functions that are defined
this way), which provides the strong exception safety in this case. I suggest to enforce that both 
member swap and non-member swap of <tt>std::function</tt> are nothrow functions as it had been guaranteed 
since TR1 on.
</p>

<p><i>[
2011 Bloomington
]</i></p>

<p>
Dietmar: May not be swappable in the first place.
</p>
<p>
Alisdair: This is wide contact. Then we should be taking noexcept off instead of putting it on. This is preferred resolution.
</p>
<p>
Pablo: This is bigger issue. Specification of assignment in terms of swap is suspect to begin with. It is over specification.
How this was applied to string is a better example to work from.
</p>
<p>
Pablo: Two problems: inconsistency that should be fixed (neither should have noexcept), the other issues is that assignment
should not be specified in terms of swap. There are cases where assignment should succeed where swap would fail. This is easier
with string as it should follow container rules.
</p>
<p>
<b>Action Item</b> (Alisdair): There are a few more issues found to file.
</p>
<p>
Dave: This is because of allocators? The allocator makes this not work.
</p>
<p>
Howard: There is a type erased allocator in shared_ptr. There is a noexcept allocator in shared_ptr.
</p>
<p>
Pablo: shared_ptr is a different case. There are shared semantics and the allocator does move around.
A function does not have shared semantics.
</p>
<p>
Alisdair: Function objects think they have unique ownership.
</p>
<p>
Howard: In function we specify semantics with copy construction and swap.
</p>
<p>
<b>Action Item</b> (Pablo): Write this up better (why assignment should not be defined in terms of swap)
</p>
<p>
Howard: Not having trouble making function constructor no throw.
</p>
<p>
Dietmar: Function must allocate memory.
</p>
<p>
Howard: Does not put stuff that will throw on copy or swap in small object optimization. Put those on heap.
Storing allocator, but has to be no throw copy constructable.
</p>
<p>
Pablo: Are you allowed to or required to swap or move allocators in case or swap or move.
</p>
<p>
Dave: An allocator that is type erased should be different...
</p>
<p>
Pablo: it is
</p>
<p>
Dave: Do you need to know something about allocator types? But only at construction time.
</p>
<p>
Pablo: You could have allocators that are different types.
</p>
<p>
Dave: Swap is two ended operation.
</p>
<p>
Pablo: Opinion is that both have to say propagate on swap for them to swap.
</p>
<p>
John: It is not arbitrary. If one person says no. No is no.
</p>
<p>
Howard: Find noexcept swap to be very useful. Would like to move in that direction and bring container design along.
</p>
<p>
Dave: If you have something were allocator must not propagate you can detect that at construction time.
</p>
<p>
...
</p>
<p>
Pablo: Need to leave this open and discuss in smaller group.
</p>
<p>
Alisdair: Tried to add boost::any as TR2 proposal and ran into this issue. Only the first place where we run into
issues with type erased allocators. Suggest we move it to open.
</p>
<p>
<b>Action Item</b>: Move to open.
</p>
<p>
<b>Action Item</b> (Pablo works with Howard and Daniel): Address the more fundamental issue
(which may be multiple issues) and write up findings.
</p>

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

<blockquote class="note">
<p>This wording is relative to the FDIS.</p>
<ol>
<li><p>Modify the header <tt>&lt;functional&gt;</tt> synopsis in 20.14 [function.objects] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

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

<li><p>Modify the class template <tt>function</tt> synopsis in 20.14.12.2 [func.wrap.func] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  <i>// [func.wrap.func.alg], specialized algorithms:</i>
  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

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

<li><p>Modify 20.14.12.2.7 [func.wrap.func.alg] as indicated:</p>
<blockquote><pre>
template&lt;class R, class... ArgTypes&gt;
void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2) <ins>noexcept</ins>;
</pre><blockquote><p>
-1- <i>Effects</i>: <tt>f1.swap(f2);</tt>
</p></blockquote></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2014-02-28 (Post Issaquah), Pablo provides more information]</i></p>


<p>
For cross-referencing purposes: The resolution of this issue should be
harmonized with any resolution to LWG <a href="lwg-active.html#2370">2370</a>, which addresses
inappropriate <tt>noexcept</tt>s in some function constructors.
</p>

<p>We have the following choices:</p>

<ol>
<li>
<p><tt>swap()</tt> does not throw</p>

<blockquote><p>
<i>Discussion</i>: This definition is desirable, and allows assignment
   to be implemented with the strong exception guarantee, but it does have
   consequences: The implementation cannot use the small-object optimization
   for a function-object <tt>F</tt> unless <tt>F</tt> is <tt>NothrowMovable</tt> 
   (nothrow-swappable is unimportant because <tt>F</tt> is not swapped with another <tt>F</tt>). 
   Note that many functors written before C++11 will not have move constructors decorated
   with <tt>noexcept</tt>, so this limitation could affect a lot of code.
</p>
<p>
It is not clear what other implementation restrictions might be
   needed. Allocators are required not to throw on move or copy. Is that
   sufficient?
</p>
</blockquote>
</li>

<li>
<p><tt>swap()</tt> can throw</p>

<blockquote>
<p>
<i>Discussion</i>: This definition gives maximum latitude to implementation to
   use small-object optimization. However, the strong guarantee on assignment
   is difficult to achieve.  Should we consider giving up on the strong
   guarantee? How much are we willing to pessimize code for exceptions?
</p>
</blockquote>
</li>
<li>
<p><tt>swap()</tt> will not throw if both functions have <tt>NoThrowMoveable</tt> functors</p>

<blockquote>
<p>
<i>Discussion</i>: This definition is similar to option 2, but gives slightly
  stronger guarantees.  Here, <tt>swap()</tt> can throw, but the programmer can
  theoretically prevent that from happening. This should be straight-forward
  to implement and gives the implementation a lot of latitude for
  optimization. However, because this is a dynamic decision, the program is
  not as easy to reason about. Also, the strong guarantee for assignment is
  compromized as in option 2.
</p>
</blockquote>
</li>
</ol>

<p><i>[2016-08-02, Ville, Billy, and Billy comment and reinstantiate the original P/R]</i></p>

<p>
We (Ville, Billy, and Billy) propose to require that <tt>function</tt>'s <tt>swap</tt> is <tt>noexcept</tt> 
in all cases.
</p>
<ul>
<li><p>libstdc++ does not throw in their <tt>swap</tt>. It is not <tt>noexcept</tt> today, but the small functor 
optimization only engages for trivially copyable types.</p></li>
<li><p>msvc++ checks <tt>is_nothrow_move_constructible</tt> before engaging the small functor optimization and marks 
its <tt>swap</tt> <tt>noexcept</tt></p></li>
<li><p>libc++ marks <tt>swap</tt> <tt>noexcept</tt> (though I have not looked at its implementation)</p></li>
</ul>
<p>
Moreover, many of the concerns that were raised by providing this guarantee are no longer applicable now that 
<a href="http://wg21.link/p0302r1">P0302</a> has been accepted, which removes allocator support from <tt>std::function</tt>.
<p/>
Therefore we are re-proposing the original resolution above.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: Move to Tentatively Ready</p>



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

<ol>
<li><p>Modify the header <tt>&lt;functional&gt;</tt> synopsis in 20.14 [function.objects] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

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

<li><p>Modify the class template <tt>function</tt> synopsis in 20.14.12.2 [func.wrap.func] as indicated:</p>
<blockquote><pre>
namespace std {
  [&hellip;]

  <i>// [func.wrap.func.alg], specialized algorithms:</i>
  template&lt;class R, class... ArgTypes&gt;
  void swap(function&lt;R(ArgTypes...)&gt;&amp;, function&lt;R(ArgTypes...)&gt;&amp;) <ins>noexcept</ins>;

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

<li><p>Modify 20.14.12.2.7 [func.wrap.func.alg] as indicated:</p>
<blockquote><pre>
template&lt;class R, class... ArgTypes&gt;
void swap(function&lt;R(ArgTypes...)&gt;&amp; f1, function&lt;R(ArgTypes...)&gt;&amp; f2) <ins>noexcept</ins>;
</pre><blockquote><p>
-1- <i>Effects</i>: As if by: <tt>f1.swap(f2);</tt>
</p></blockquote></blockquote>
</li>
</ol>





<hr>
<h3><a name="2166" href="#2166">2166.</a> Heap property underspecified?</h3>
<p><b>Section:</b> 25.5.6 [alg.heap.operations] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Peter Sommerlad <b>Opened:</b> 2012-07-09 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.heap.operations">issues</a> in [alg.heap.operations].</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>
Another similar issue to the <tt>operator&lt;</tt> vs greater in <tt>nth_element</tt> but not as direct occurs 
in 25.5.6 [alg.heap.operations]:
</p>
<blockquote><p>
-1- A <em>heap</em> is a particular organization of elements in a range between two random access iterators 
<tt>[a,b)</tt>. Its two key properties are:
</p>
<ol>
<li>There is no element greater than <tt>*a</tt> in the range and
</li>
<li><tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in 
O(log(<tt>N</tt>)) time.
</li>
</ol>
</blockquote>
<p>
As noted by Richard Smith, it seems that the first bullet should read:
</p>
<blockquote><p>
<tt>*a</tt> is not less than any element in the range
</p></blockquote>
<p>
Even better the heap condition could be stated here directly, instead of leaving it unspecified, i.e.,
</p>
<blockquote><p>
Each element at <tt>(a+2*i+1)</tt> and <tt>(a+2*i+2)</tt> is less than the element at <tt>(a+i)</tt>, 
if those elements exist, for <tt>i&gt;=0</tt>.
</p></blockquote>
<p>
But may be that was may be intentional to allow other heap organizations?
<p/>
See also follow-up discussion of c++std-lib-32780.
<p/>

</p>
<p><i>[2016-08 Chicago]</i></p>

<p>Walter provided wording</p>
<p>Tues PM: Alisdair &amp; Billy(MS) to improve the wording.</p>

<p><i>[2016-08-02 Chicago LWG]</i></p>

<p>
Walter provides initial Proposed Resolution. Alisdair objects to perceived
complexity of the mathematical phrasing.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p><i>[Note to editor: As a drive-by editorial adjustment, please replace the current
enumerated list format by the numbered bullet items shown below.]</i></p>


<p>Change [alg.heap.operations]:</p>

<p>1 A heap is a particular organization of elements in a range between two
random access iterators [a, b)<del>. Its two key properties are</del><ins>such
that</ins>:</p>

<p>(1.1) -- <del>There is no element greater than <tt>*a</tt> in the range and</del><br/>
         <ins>For all <tt>i >= 0</tt>,<br/>
         <tt>comp(a[i], a[L])</tt> is false whenever L = 2*i+1 &lt; b-a,<br/>
         and<br/>
         <tt>comp(a[i], a[R])</tt> is false whenever R = 2*i+2 &lt; b-a.</ins><br/>
</p>
<p>(1.2) -- <tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in O(log(N)) time.</p>
</blockquote>

<p><i>[2016-08-03 Chicago LWG]</i></p>

<p>Walter and Billy O'Neal provide revised Proposed Resolution, superseding yesterday's.</p>
<p>Thurs PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 25.5.6 [alg.heap.operations] as indicated:</p>

<blockquote class="note">
<p>
Note to project editor: As a drive-by editorial adjustment, please replace the
current enumerated list format by numbered bullet items.
</p>
</blockquote>

<blockquote>
<p>
-1- A <em>heap</em> is a particular organization of elements in a range between two random access iterators 
<code>[a, b)</code><del>. Its two key properties are</del><ins>such that</ins>:
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <del>There is no element greater than <tt>*a</tt> in the range and</del>
<ins>With <math xmlns="http://www.w3.org/1998/Math/MathML">
<mi>N</mi><mo>=</mo><mi mathvariant="monospace" mathsize="small">b</mi><mo>-
</mo><mi mathvariant="monospace" mathsize="small">a</mi></math>, 
for all <math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math>,
<math xmlns="http://www.w3.org/1998/Math/MathML"><mn>0</mn><mo>&lt;</mo><mi>i</mi><mo>&lt;</mo><mi>N</mi></math>,
<code>comp(a[</code><math xmlns="http://www.w3.org/1998/Math/MathML">
  <mo rspace="0.3em" lspace="0em" stretchy="true" fence="true" form="prefix">&lfloor;</mo>
  <mrow>
	<mfrac linethickness="1">
		<mrow>
			<mi>i</mi>
			<mo>-</mo>
			<mn>1</mn>
		</mrow>
		<mn>2</mn>
	</mfrac>
  </mrow>
  <mo rspace="0em" lspace="0.3em" stretchy="true" fence="true" form="postfix">&rfloor;</mo>
</math><code>], a[<math xmlns="http://www.w3.org/1998/Math/MathML"><mi>i</mi></math>])</code> is <tt>false</tt>.</ins>
</p>
<blockquote class="note">
<p>
[Note to the project editor: In LaTeX the above insertion should be expressed as follows:
<p/>
With $N = <code>b</code>-<code>a</code>$, for all $i$, $0 &lt; i &lt; N$,
<code>comp(a[$\left \lfloor{\frac{i-1}{2}}\right \rfloor$], a[$i$])</code> is <code>false</code>.]
</p>
</blockquote>
</li>
<li><p>(1.2) &mdash; <tt>*a</tt> may be removed by <tt>pop_heap()</tt>, or a new element added by <tt>push_heap()</tt>, in 
&#x1d4aa;(log(<i>N</i>)) time.
</p>
</li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2221" href="#2221">2221.</a> No formatted output operator for <tt>nullptr</tt></h3>
<p><b>Section:</b> 27.7.3 [output.streams] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2012-12-07 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
When I write 
</p>
<blockquote><pre>
std::cout &lt;&lt; nullptr &lt;&lt; std::endl;
</pre></blockquote>
<p>
I get a compilation error, "ambiguous overload for '<tt>operator&lt;&lt;</tt>' in '<tt>std::cout &lt;&lt; nullptr</tt>'". 
As far as I can tell, the compiler is right to issue that error. There are inserters for <tt>const void*</tt>, 
<tt>const char*</tt>, <tt>const signed char*</tt>, and <tt>const unsigned char*</tt>, and none for 
<tt>nullptr_t</tt>, so the expression really is ambiguous.
<p/>
<em>Proposed wording</em>:
<p/>
The obvious library solution is to add a <tt>nullptr_t</tt> overload, which would be defined something like
</p>
<blockquote><pre>
template&lt;class C, class T&gt;
basic_ostream&lt;C, T&gt;&amp; operator&lt;&lt;(basic_ostream&lt;C, T&gt;&amp; os, nullptr_t) 
{ 
  return os &lt;&lt; (void*) nullptr; 
}
</pre></blockquote>
<p>
We might also consider addressing this at a core level: add a special-case language rule that addresses all 
cases where you write <tt>f(nullptr)</tt> and <tt>f</tt> is overloaded on multiple pointer types. (Perhaps 
a tiebreaker saying that <tt>void*</tt> is preferred in such cases.)
</p>

<p><i>[2016-01-18, comments from Mike and Ville collected by Walter Brown]</i></p>

<p>
<b>Mike Miller</b>: "Changing overload resolution sounds like something that should be
considered by EWG before CWG [&hellip;]"
<p/>
<b>Ville</b>: "Agreed, such a change would be Evolutionary. Personally, I think it would also be wrong, because 
I don't see how <tt>void*</tt> is the right choice to prefer in the case of code that is currently ambiguous. 
Sure, it would solve this particular library issue, but it seemingly has wider repercussions. If LWG really wants 
to, EWG can certainly discuss this issue, but I would recommend solving it on the LWG side (which doesn't mean 
that the standard necessarily needs to change, I wouldn't call it far-fetched to NAD it)."
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Zhihao recommends NAD:</p>
<p>
<tt>nullptr</tt> is printable if being treated as <tt>void*</tt>, but causes
UB if being treated as <tt>char cv*</tt>. Capturing this ambigurity
at compile time and avoid a runtime UB is a good thing.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: General agreement on providing the overload; discussion on what it should say.</p>
<p>Polls:<br/>
Matt's suggestion (in the issue): 2/0/6/2/2/<br/>
Unspecified output: 3/2/5/0/1<br/>
Specified output: 1/1/6/3/0</p>
<p>Move to Open</p>

<p><i>[2016-08 Chicago]</i></p>

<p>
The group consensus is that we only output <tt>nullptr</tt> because
it is of a fundamental type, causing problems in functions doing
forwarding, and we don't want to read it back.
</p>
<p>Fri PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Insert the signature into 27.7.3.1 [ostream], class template <tt>basic_ostream</tt> synopsis, as follows:</p>

<blockquote class="note">
<p>
[<i>Drafting notes:</i> Why member?  Don't want to define a new category of inserters just for this.]
</p>
</blockquote>

<blockquote>
<pre>
namespace std {
  template &lt;class charT, class traits = char_traits&lt;charT&gt; &gt;
  class basic_ostream
    : virtual public basic_ios&lt;charT, traits&gt; {
  public:
    [&hellip;]
    basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(const void* p);
    <ins>basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(nullptr_t);</ins>
    basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(
      basic_streambuf&lt;char_type, traits&gt;* sb);
    [&hellip;]
  };
</pre>
</blockquote>
</li>

<li><p>Append the following new paragraphs to 27.7.3.6.3 [ostream.inserters]:</p>

<blockquote>
<pre>
basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;
  (basic_streambuf&lt;charT, traits&gt;* sb);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-10- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
<pre>
<ins>basic_ostream&lt;charT, traits&gt;&amp; operator&lt;&lt;(nullptr_t);</ins>
</pre>
<blockquote>
<p>
<ins>-??- <i>Effects:</i> Equivalent to <tt>return *this &lt;&lt; s;</tt> where
<tt>s</tt> is an implementation-defined NTCTS.</ins>
</p>
</blockquote>

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





<hr>
<h3><a name="2223" href="#2223">2223.</a> <tt>shrink_to_fit</tt> effect on iterator validity</h3>
<p><b>Section:</b> 23.3.11.3 [vector.capacity] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Juan Soulie <b>Opened:</b> 2012-12-17 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#vector.capacity">active issues</a> in [vector.capacity].</p>
<p><b>View all other</b> <a href="lwg-index.html#vector.capacity">issues</a> in [vector.capacity].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>

<p>
After the additions by <a href="lwg-defects.html#2033">2033</a>, it appears clear that the intended effect includes a reallocation and 
thus the potential effect on iterators should be explicitly added to the text in order to not contradict 
23.2.1 [container.requirements.general]/11, or at the very least, explicitly state that a reallocation may 
happen.
<p/>
Taking consistency with "reserve" into consideration, I propose:
</p>
<ul>
<li><p>
that the current "Remarks" are made its "Effect" instead, inserting "Reallocation happens at this point if and only 
if the function effectively reduces the capacity." after the note on non-bindingness.
</p>
</li>
<li><p>
adding a "Remarks" paragraph, similar to that of reserve: "Reallocation invalidates all the references, pointers, 
and iterators referring to the elements in the sequence."
</p></li>
</ul>
<p>
BTW, while we are at it, I believe the effect on iterators should also be explicitly stated in the other instance 
a reallocation may happen: 23.3.11.5 [vector.modifiers]/1 &mdash; even if obvious, it only contradicts 
23.2.1 [container.requirements.general]/11 implicitly. 
<p/>
I propose to also insert "Reallocation invalidates all the references, pointers, and iterators referring to the 
elements in the sequence." at the appropriate location in its "Remarks".
</p>

<p><i>[2012-12-19: Jonathan Wakely comments]</i></p>


<p>
The described problem also affects <tt>std::basic_string</tt> and <tt>std::deque</tt>.
</p>

<p><i>[2013-03-15 Issues Teleconference]</i></p>

<p>
Moved to Review.
</p>

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

<p>Daniel extends the P/R.</p>

<p>Rationale:</p>

<p>The wording in 21.3.1.4 [string.capacity] combined with 21.3.1.1 [string.require]
seems to say the necessary things. We cannot impose all requirements as we do for <tt>vector</tt>, because
we want to allow the short-string-optimization.</p>


<p><i>[2014-02-15 post-Issaquah session]</i></p>

<p>
STL: I think that <tt>shrink_to_fit</tt> should be a no-op when called twice.
</p>
<p>
STL: Do we ever define reallocation for <tt>deque</tt>? Nope, all mentions of "reallocation" are in <tt>vector</tt>.
     We define what it means in <tt>vector::reserve()</tt>, but not for <tt>deque</tt>.
</p>
<p>
STL: Oh duh, they define reallocate in the PR. But I think we can do better here.
</p>
<p>
STL: Optimally, deque shrinking just allocates a new map of pointers, and drops empty blocks, but preserves pointers/references to elements.
</p>
<p>
Alisdair: That's like unordered containers, invalidating only iterators.
</p>
<p>
Pablo: It doesn't make sense to reduce <tt>capacity()</tt> to <tt>size()</tt>, because <tt>deque</tt> doesn't have capacity!
</p>
<p>
STL: For <tt>vector</tt>, "effectively reduces the capacity" is unnecessary, the capacity there is observable.
</p>
<p>
STL: There is a strong reason to provide an optimal shrink to fit for <tt>deque</tt>, since only the library implementer can do this.
</p>
<p>
STL: The other thing I don't like the repeated definition of reallocation for <tt>vector</tt>, we define it once and use it in a bunch of places.
     At most we can lift it up to the <tt>vector</tt> synopsis.
</p>
<p>
STL: I'll write new wording.
</p>

<p><i>[2014-10-01, STL adds discussion and provides new wording]</i></p>

<p>
Compared to the previous proposed resolution:
</p>
<ul>
<li><p>
I'm changing <tt>basic_string</tt>'s wording because (1) we should guarantee that capacity won't increase, (2) we should mention 
that it's linear complexity, and (3) we can provide a better invalidation guarantee than 21.3.1.1 [string.require]/5.  
(As previously noted, we already have the strong exception guarantee.) This introduces the term "reallocation" into 
<tt>basic_string</tt>, but immediately explains what it means for iterator validity. As far as I can tell, the Small String 
Optimization doesn't complicate the wording here; it's a reason why an implementation might not honor the request, but if 
the capacity is reduced, we are definitely reallocating buffers and will invalidate everything (including when the destination 
is the small buffer).
</p></li>
<li><p>
Between N3485 and N3936, <tt>deque</tt>'s wording was updated to avoid talking about <tt>capacity()</tt> which it doesn't have.  
Since the container's capacity is unobservable, I'm saying that invalidation is unconditional.
</p></li>
<li><p>
In <tt>vector</tt>'s wording, I'm also guaranteeing that capacity won't increase, and that iterators/etc. remain valid if the 
capacity is unchanged.
</p></li>
</ul>
<p>
My wording doesn't directly say that <tt>shrink_to_fit()</tt> should be a no-op when called twice in a row. (Indirectly, 
if the first call reduces <tt>capacity()</tt> to <tt>size()</tt>, the second call must preserve iterators/etc.) I considered 
rewording the complexity to say "linear if reallocation happens", but that's potentially problematic (what if we copy almost 
all <tt>N</tt> elements, then one throws and we have to unwind? There are no effects, so reallocation didn't happen, yet we 
took longer than constant time). Implementers can always do better than the stated complexity bounds.
<p/>
I chose not to modify <tt>deque</tt>'s requirements, so implementations remain free to reallocate the elements themselves.
<p/>
I didn't attempt to centralize vector's reallocation wording. That can be done editorially, if someone is sufficiently motivated.
</p>

<p><strong>Previous resolution from Juan Soulie/Daniel [SUPERSEDED]:</strong></p>

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

<ol>
<li><p>Keep 21.3.1.4 [string.capacity] around p14 <em>unchanged</em>, because we don't speak about
reallocations and we give the strong exception guarantee in 21.3.1.1 [string.require] (Invalidation
specification also at that place):</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-14- <i>Remarks</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ].
</p>
</blockquote>
</li>

<li><p>Edit 23.3.8.3 [deque.capacity] around p7 as indicated:</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-5- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] Reallocation happens at this point if and only 
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins> 
<p/>
-6- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-7- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all 
the references, pointers, and iterators referring to the elements in the sequence.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 23.3.11.3 [vector.capacity] around p7 as indicated:</p>
<blockquote><pre>
void shrink_to_fit();
</pre>
<p>
-7- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] Reallocation happens at this point if and only 
if the function effectively reduces the capacity. If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins> 
<p/>
-8- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-9- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to 
<tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i> ] If an exception is thrown other than by the move constructor 
of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</del><ins>Reallocation invalidates all 
the references, pointers, and iterators referring to the elements in the sequence.</ins>
</p>
</blockquote>
</li>

<li><p>Edit 23.3.11.5 [vector.modifiers] p1 as indicated:</p>
<blockquote><pre>
iterator insert(const_iterator position, const T&amp; x);
iterator insert(const_iterator position, T&amp;&amp; x);
iterator insert(const_iterator position, size_type n, const T&amp; x);
template &lt;class InputIterator&gt;
iterator insert(const_iterator position, InputIterator first, InputIterator last);
iterator insert(const_iterator position, initializer_list&lt;T&gt;);
template &lt;class... Args&gt; void emplace_back(Args&amp;&amp;... args);
template &lt;class... Args&gt; iterator emplace(const_iterator position, Args&amp;&amp;... args);
void push_back(const T&amp; x);
void push_back(T&amp;&amp; x);
</pre>
<p>
-1- <i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. <ins>Reallocation 
invalidates all the references, pointers, and iterators referring to the elements in the sequence.</ins> If 
no reallocation happens, all the iterators and references before the insertion point remain valid. If an 
exception is thrown other than by the copy constructor, move constructor, assignment operator, or move 
assignment operator of <tt>T</tt> or by any <tt>InputIterator</tt> operation there are no effects. If an 
exception is thrown by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt>, the effects are unspecified.
</p>
</blockquote>
</li>
</ol>

</blockquote>

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

<p>
GR: I'm concerned that <tt>shrink_to_fit</tt> may cause reallocation without changing the capacity. [&hellip;] 
It's about correctness. The statement about invalidation is useless if I cannot detect whether reallocation has happened?
<p/>
AM: It seems like the logic goes the other way round: It's the capacity change that causes reallocation, so if 
there's no capacity change, there's no reallocation. But that's not quite how I'd like to say it... maybe this, : 
"If capacity does not change, no reallocation occurs."
<p/>
GR: Where does it actually say that <tt>reserve()</tt> invalidates? AM: It should say that in the container requirements. 
VV: vector specifies in <tt>reserve</tt> that there's reallocation if and only if the capacity changes. GR: I can't find
anything in the container requirements about <tt>reserve</tt>. DK: No, it's specified for every container separately. 
GR: It isn't specified for string.
<p/>
GR: I'm noticing that the issue touches on <tt>shrink_to_fit</tt> for a bunch of containers. Anyway, I think the 
reserve issue [re string] is in scope for this issue. This change is touching on a lot of members.
<p/>
AM: Landing this change will provide clarity for what we should do with <tt>basic_string</tt>. GR: We're already asking 
for changes; we should fix string as well. AM: If one of the changes is ready before the other, I'd like to land the 
finished part first, but if both are ready for Lenexa, I'm equally happy to fix them in one go.
<p/>
DK will reword this. 
<p/>
<b>Conclusion</b>: Update wording, revisit in Lenexa. 
</p>
<p><i>[2016-08 Chicago]</i></p>

<p>Monday PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 21.3.1.4 [string.capacity] p14 as depicted:</p>

<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
-14- <i><del>Remarks</del><ins>Effects</ins></i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce 
<tt>capacity()</tt> to <tt>size()</tt>. [<i>Note</i>: The request is non-binding to allow latitude for 
implementation-specific optimizations. &mdash; <i>end note</i>] <ins>It does not increase <tt>capacity()</tt>, 
but may reduce <tt>capacity()</tt> by causing reallocation.</ins>
<p/>
<ins>-?- <i>Complexity</i>: Linear in the size of the sequence.</ins>
<p/>
<ins>-?- <i>Remarks</i>: Reallocation invalidates all the references, pointers, and iterators referring to the 
elements in the sequence. If no reallocation happens, they remain valid.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.8.3 [deque.capacity] p5-p7 as depicted:</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
-5- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce memory use but does not change 
the size of the sequence. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific 
optimizations. &mdash; <i>end note</i>] If an exception is thrown other than by the move constructor of a 
non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
<p/>
-6- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-7- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce memory use but does not change the
size of the sequence. [<i>Note</i>: The request is non-binding to allow latitude for implementation-specific
optimizations. &mdash; <i>end note</i>]</del><ins><tt>shrink_to_fit</tt> invalidates all the references, pointers, 
and iterators referring to the elements in the sequence.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.11.3 [vector.capacity] p7-p9 as depicted:</p>
<blockquote>
<pre>
void shrink_to_fit();
</pre>
<blockquote>
<p>
-7- <i>Requires</i>: <tt>T</tt> shall be <tt>MoveInsertable</tt> into <tt>*this</tt>.
<p/>
<ins>-?- <i>Effects</i>: <tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to <tt>size()</tt>. 
[<i>Note</i>: The request is non-binding to allow latitude for implementation-specific optimizations. &mdash; <i>end note</i>] 
It does not increase <tt>capacity()</tt>, but may reduce <tt>capacity()</tt> by causing reallocation. If an exception is 
thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt> there are no effects.</ins>
<p/>
-8- <i>Complexity</i>: Linear in the size of the sequence.
<p/>
-9- <i>Remarks</i>: <del><tt>shrink_to_fit</tt> is a non-binding request to reduce <tt>capacity()</tt> to <tt>size()</tt>. 
[<i>Note</i>: The request is non-binding to allow latitude for implementation-specific optimizations. &mdash; <i>end 
note</i>] If an exception is thrown other than by the move constructor of a non-<tt>CopyInsertable</tt> <tt>T</tt> there 
are no effects.</del><ins>Reallocation invalidates all the references, pointers, and iterators referring to the elements 
in the sequence. If no reallocation happens, they remain valid.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 23.3.11.5 [vector.modifiers] p1 as depicted:</p>

<blockquote>
<p>
-1- <i>Remarks</i>: Causes reallocation if the new size is greater than the old capacity. <ins>Reallocation invalidates all 
the references, pointers, and iterators referring to the elements in the sequence.</ins> If no reallocation happens,
all the iterators and references before the insertion point remain valid. [&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2261" href="#2261">2261.</a> Are containers required to use their '<tt>pointer</tt>' type internally?</h3>
<p><b>Section:</b> 23.2 [container.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2013-05-14 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#container.requirements">active issues</a> in [container.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#container.requirements">issues</a> in [container.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Is a container <tt>C</tt> only supposed to refer to allocated memory (blocks of
contiguous storage, nodes, etc.) through objects of type <tt>C::pointer</tt>
rather than <tt>C::value_type*</tt>?
</p>

<p>
I don't see anything explicitly requiring this, so a container could
immediately convert the result of <tt>get_allocator().allocate(1)</tt> to a
built-in pointer of type <tt>value_type*</tt> and only deal with the built-in
pointer until it needs to deallocate it again, but that removes most
of the benefit of allowing allocators to use custom pointer types.
</p>

<p><i>[2014-06-12, Jonathan comments]</i></p>

<p>
This issue is basically the same issue as LWG <a href="lwg-active.html#1521">1521</a>, which agrees it's an issue, 
to be dealt with in the future, so I request that <a href="lwg-active.html#2261">2261</a> not be closed as a dup 
unless we reopen <a href="lwg-active.html#1521">1521</a>.
</p>

<p><i>[2016-08, Zhihao comments]</i></p>

<p>The <tt>pointer</tt> types are not exposed in the container interface,
and we consider that the memory allocation constraints
"all containers defined in this clause obtain memory using an
allocator" already implies the reasonable expectation.  We
propose the fix as non-normative.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: General agreement on direction, Alisdair and Billy to update wording</p>
<p>Fri AM: Moved to Tentatively Ready</p>


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

<p><i>[Drafting notes: if people prefer this to be normative, strip
the "Note" markups.]</i></p>


<p>Modify 23.2.1 [container.requirements.general]/8 as indicated:</p>

<blockquote><p>
Unless otherwise specified, all containers defined in this clause obtain
memory using an allocator (see 17.6.3.5 [allocator.requirements]).
<ins>[<i>Note:</i> In particular, containers and iterators
do not store references to allocated elements other than through the
allocator's pointer type, i.e., as objects of type <tt><i>P</i></tt> or
<tt>pointer_traits&lt;<i>P</i>&gt;::template rebind&lt;<i>unspecified</i>&gt;</tt>,
where <tt><i>P</i></tt> is
<tt>allocator_traits&lt;allocator_type&gt;::pointer</tt>. &mdash; <i>end note</i>]</ins>
</p></blockquote>





<hr>
<h3><a name="2394" href="#2394">2394.</a> <tt>locale::name</tt> specification unclear &mdash; what is implementation-defined?</h3>
<p><b>Section:</b> 22.3.1.3 [locale.members] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-06-09 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#locale.members">issues</a> in [locale.members].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
22.3.1.3 [locale.members] p5 says:
</p>
<blockquote><p>
<i>Returns</i>: The name of <tt>*this</tt>, if it has one; otherwise, the string <tt>"*"</tt>. If <tt>*this</tt> has a name, then
<tt>locale(name().c_str())</tt> is equivalent to <tt>*this</tt>. Details of the contents of the resulting string are
otherwise implementation-defined.
</p></blockquote>
<p>
So&hellip; what is implementation-defined here, exactly? The first sentence <em>completely</em> defines the behavior of this function 
in all cases.
<p/>
Also, the second sentence says (effectively) that all locales with the same name are equivalent: given <tt>L1</tt> and <tt>L2</tt> 
that have the same name <tt>N</tt>, they are both equivalent to <tt>locale(N)</tt>, and since there is no definition of 
"equivalent" specific to <tt>locale</tt>, I assume it's the normal transitive equivalence property, which would imply that 
<tt>L1</tt> is equivalent to <tt>L2</tt>. I'm not sure why this central fact is in the description of <tt>locale::name</tt>, nor 
why it's written in this roundabout way.
</p>

<p><i>[2016-08-03 Chicago LWG]</i></p>

<p>
Walter, Nevin, and Jason provide initial Proposed Resolution.
</p>
<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 22.3.1.3 [locale.members] as indicated:</p>

<blockquote>
<pre>
basic_string&lt;char&gt; name() const;
</pre>
<blockquote>
<p>
-5- <i>Returns:</i> The name of <tt>*this</tt>, if it has one; otherwise, the string <tt>"*"</tt>. 
<del>If <tt>*this</tt> has a name, then <tt>locale(name().c_str())</tt> is equivalent to <tt>*this</tt>. 
Details of the contents of the resulting string are
otherwise implementation-defined.</del>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2460" href="#2460">2460.</a> LWG issue 2408 and value categories</h3>
<p><b>Section:</b> 20.15.7.6 [meta.trans.other], 24.4.1 [iterator.traits] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2014-11-19 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.trans.other">active issues</a> in [meta.trans.other].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.trans.other">issues</a> in [meta.trans.other].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG issue <a href="lwg-defects.html#2408">2408</a> changes the meat of the specification of <tt>common_type</tt> to compute:
</p>
<blockquote><p>
[&hellip;] the type, if any, of an unevaluated conditional expression (5.16) whose first operand is an 
arbitrary value of type <tt>bool</tt>, whose second operand is an <tt>xvalue</tt> of type <tt>T1</tt>, 
and whose third operand is an xvalue of type <tt>T2</tt>.
</p></blockquote>
<p>
This has an effect on the specification that I think was unintended. It used to be the case that 
<tt>common_type&lt;T&amp;, U&amp;&amp;&gt;</tt> would consider the type of a conditional between an 
lvalue of type <tt>T</tt> and an xvalue of type <tt>U</tt>. It's now either invalid (because there is 
no such thing as an xvalue of reference type) or considers the type of a conditional between an xvalue 
of type <tt>T</tt> and an xvalue of type <tt>U</tt>, depending on how you choose to read it.
<p/>
Put another way, this has the effect of changing the usual definition from:
</p>
<blockquote><pre>
typedef decay_t&lt;decltype(true ? declval&lt;T&gt;() : declval&lt;U&gt;())&gt; type;
</pre></blockquote>
<p>
to:
</p>
<blockquote><pre>
typedef decay_t&lt;decltype(true ? declval&lt;remove_reference_t&lt;T&gt;&gt;() : declval&lt;remove_reference_t&lt;U&gt;&gt;())&gt; type;
</pre></blockquote>
<p>
It also makes <tt>common_type</tt> underspecified in the case where one of the operands is of type <tt>void</tt>; 
in that case, the resulting type depends on whether the expression is a throw-expression, which is not 
specified (but used to be).
<p/>
Also on the subject of this wording: the changes to 24.4.1 [iterator.traits] say that 
<tt>iterator_traits&lt;T&gt;</tt> "shall have no members" in some cases. That's wrong. It's a class type; 
it always has at least a copy constructor, a copy assignment operator, and a destructor. Plus this 
removes the usual library liberty to add additional members with names that don't collide with normal 
usage (for instance, if a later version of the standard adds members, they can't be present here as a 
conforming extension). Perhaps this should instead require that the class doesn't have members with any 
of those five names? That's what <a href="lwg-defects.html#2408">2408</a> does for <tt>common_type</tt>'s type member.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>This issue has two parts, one dealing with <tt>common_type</tt>, the other with <tt>iterator_traits</tt>. 
The first of these is resolved by <a href="lwg-active.html#2465">2465</a>.  See below for the proposed resolution for the other one.</p>
<p>Wed PM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>Change 24.4.1 [iterator.traits] p.2:</p>

<p>[&hellip;] as publicly accessible members <del>and no other members</del>:</p>

<p>[&hellip;]</p>

<p>Otherwise, <tt>iterator_traits&lt;Iterator&gt;</tt> shall have no members <ins>by any of the above names</ins>.</p>





<hr>
<h3><a name="2468" href="#2468">2468.</a> Self-move-assignment of library types</h3>
<p><b>Section:</b> 17.6.4.9 [res.on.arguments], 17.6.3.1 [utility.arg.requirements], 17.6.5.15 [lib.types.movedfrom], 23.2.1 [container.requirements.general] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Matt Austern <b>Opened:</b> 2015-01-22 <b>Last modified:</b> 2016-10-07</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#res.on.arguments">issues</a> in [res.on.arguments].</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>
Suppose we write
</p>
<blockquote>
<pre>
vector&lt;string&gt; v{"a", "b", "c", "d"};
v = move(v);
</pre>
</blockquote>
<p>
What should be the state of <tt>v</tt> be? The standard doesn't say anything specific about self-move-assignment. 
There's relevant text in several parts of the standard, and it's not clear how to reconcile them.
<p/>
17.6.4.9 [res.on.arguments] writes that, for all functions in the standard library, unless explicitly stated 
otherwise, "If a function argument binds to an rvalue reference parameter, the implementation may assume that this 
parameter is a unique reference to this argument." The <tt>MoveAssignable</tt> requirements table in 
17.6.3.1 [utility.arg.requirements] writes that, given <tt>t = rv</tt>, <tt>t</tt>'s state is equivalent to 
<tt>rv</tt>'s from before the assignment and <tt>rv</tt>'s state is unspecified (but valid). For containers 
specifically, the requirements table in 23.2.1 [container.requirements.general] says that, given <tt>a = rv</tt>, 
<tt>a</tt> becomes equal to what <tt>rv</tt> was before the assignment (and doesn't say anything about <tt>rv</tt>'s 
state post-assignment).
<p/>
Taking each of these pieces in isolation, without reference to the other two:
</p>
<ul>
<li><p>17.6.4.9 [res.on.arguments] would clearly imply that the effect of <tt>v = move(v)</tt> is undefined.</p></li>
<li><p>17.6.3.1 [utility.arg.requirements] would clearly imply that <tt>v = move(v)</tt> has defined behavior. 
It might be read to imply that this is a no-op, or might be read to imply that it leaves <tt>v</tt> in a valid but 
unspecified state; I'm not sure which reading is more natural.</p></li>
<li><p>23.2.1 [container.requirements.general] would clearly imply that <tt>v = move(v)</tt> is a no-op.</p></li>
</ul>
<p>
It's not clear from the text how to put these pieces together, because it's not clear which one takes precedence.  
Maybe 17.6.4.9 [res.on.arguments] wins (it imposes an implicit precondition that isn't mentioned in the 
<tt>MoveAssignable</tt> requirements, so <tt>v = move(v)</tt> is undefined), or maybe 
23.2.1 [container.requirements.general] wins (it explicitly gives additional guarantees for 
<tt>Container::operator=</tt> beyond what's guaranteed for library functions in general, so <tt>v = move(v)</tt> 
is a no-op), or maybe something else.
<p/>
On the existing implementations that I checked, for what it's worth, <tt>v = move(v)</tt> appeared to clear the vector; 
it didn't leave the vector unchanged and it didn't cause a crash.
<p/>
<em>Proposed wording</em>:
<p/>
Informally: change the <tt>MoveAssignable</tt> and Container requirements tables (and any other requirements tables 
that mention move assignment, if any) to make it explicit that <tt>x = move(x)</tt> is defined behavior and it leaves 
<tt>x</tt> in a valid but unspecified state. That's probably not what the standard says today, but it's probably what 
we intended and it's consistent with what we've told users and with what implementations actually do.
</p>

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

<p>JW: So far, the library forbids self-assignment since it assumes that anything bound to an rvalue reference has no aliases. But self-assignment can happen in real code, and it can be implemented. So I want to add an exception to the Standard that this should be allowed and leave the object in a valid-but-unspecified state.</p>
<p>STL: When this is resolved, I want to see a) VBU for library types after self-move, but also b) requirements on user types for self-moves. E.g. should algorithms be required to avoid self-assignments (since a user-defined type might blow up)? HH: In other words, should we require that you can assign from moved-from values.</p>
<p>WEB: What can one generally do with moved-from values?</p>
<p>VV: Call any member function that has no preconditions.</p>
<p>JW: That's certainly the library requirement, and it's also good guidance for user types.</p>
<p>JW: I'm writing wording. I care about this.</p>
<p>Move to Open; Jonathan to provide wording</p>

<p><i>[2016-08-01, Howard provided wording]</i></p>


<p><i>[2016-08 Chicago]</i></p>

<p>Tuesday AM: Move to Tentatively Ready</p>

<p>
<strong>Previous resolution [SUPERSEDED]:</strong>
</p>
<blockquote class="note">
<p>
In 17.6.3.2 [swappable.requirements], modify Table 23 &mdash; <code>MoveAssignable</code> requirements [moveassignable]:
</p>

<blockquote>

<table border="1">
<caption>Table 23 &mdash; <tt>MoveAssignable</tt> requirements [moveassignable]</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>

<tr>
<td><tt>t = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td><tt>t</tt></td>
<td><ins>If <tt>addressof(t) != addressof(rv)</tt>,</ins> <tt>t</tt> is
equivalent to the value of <tt>rv</tt> before the assignment</td>
</tr>

<tr>
<td colspan="4">
<tt>rv</tt>'s state is unspecified. [<i>Note:</i> <tt>rv</tt> must
still meet the requirements of the library component that is using it<ins>,
whether or not <tt>addressof(t) == addressof(rv)</tt></ins>. The
operations listed in those requirements must work as specified whether
<tt>rv</tt> has been moved from or not. &mdash; <i>end note</i>] </td>
</tr>

</table>

</blockquote>

</blockquote>

<p><i>[2016-08-07, Daniel reopens]</i></p>

<p>
With the acceptance of LWG <a href="lwg-active.html#2598">2598</a>, the proposed wording is invalid code, because it attempts to
call <code>std::addressof</code> with an rvalue argument. It should be pointed out that the new restriction 
caused by <a href="lwg-active.html#2598">2598</a> doesn't affect real code, because any identity test within a move assignment
operator (or any comparable function) would act on the current function argument, which is an lvalue in the
context of the function body. The existing wording form of the issue could still be kept, if a helper variable
would be introduced such as:
</p>
<blockquote><p>
<ins>Let <code>refrv</code> denote a reference initialized as if by <code>const T&amp; refrv = rv;</code>. Then 
if <code>addressof(t) != addressof(refrv)</code>,</ins> <code>t</code> is equivalent to the value of <code>rv</code> 
before the assignment
</p></blockquote>
<p>
But it seems to me that the same effect could be much easier realized by replacing the code form by 
a non-code English phrase that realizes the same effect.
</p>

<p><i>[2016-09-09 Issues Resolution Telecon]</i></p>

<p>Move to Tentatively Ready</p>

<p><i>[2016-10-05, Tim Song comments]</i></p>

<p>
The current P/R of LWG 2468 simply adds to <tt>MoveAssignable</tt> the requirement to tolerate self-move-assignment, 
but that doesn't actually do much about self-move-assignment of library types. Very few types in the library are 
explicitly required to satisfy <tt>MoveAssignable</tt>, so as written the restriction in 17.6.4.9 [res.on.arguments] 
would seem to still apply for any type that's not explicitly required to be <tt>CopyAssignable</tt> or <tt>MoveAssignable</tt>.
<p/>
The current P/R also doesn't address the issue with 23.2.1 [container.requirements.general] noted in the issue discussion.
</p>


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

<ol>
<li><p> In 17.6.3.2 [swappable.requirements], modify Table 23 &mdash; <code>MoveAssignable</code> 
requirements [moveassignable]:</p>

<blockquote>

<table border="1">
<caption>Table 23 &mdash; <tt>MoveAssignable</tt> requirements [moveassignable]</caption>
<tr>
<th>Expression</th>
<th>Return type</th>
<th>Return value</th>
<th>Post-condition</th>
</tr>

<tr>
<td><tt>t = rv</tt></td>
<td><tt>T&amp;</tt></td>
<td><tt>t</tt></td>
<td><ins>If <code>t</code> and <code>rv</code> do not refer to the same object,</ins> <tt>t</tt> is
equivalent to the value of <tt>rv</tt> before the assignment</td>
</tr>

<tr>
<td colspan="4">
<tt>rv</tt>'s state is unspecified. [<i>Note:</i> <tt>rv</tt> must
still meet the requirements of the library component that is using it<ins>,
whether or not <code>t</code> and <code>rv</code> refer to the same object</ins>. The
operations listed in those requirements must work as specified whether
<tt>rv</tt> has been moved from or not. &mdash; <i>end note</i>] </td>
</tr>

</table>

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





<hr>
<h3><a name="2475" href="#2475">2475.</a> Allow overwriting of <tt>std::basic_string</tt> terminator with <tt>charT()</tt> to allow 
cleaner interoperation with legacy APIs</h3>
<p><b>Section:</b> 21.3.1.5 [string.access] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Matt Weber <b>Opened:</b> 2015-02-21 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#string.access">issues</a> in [string.access].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
It is often desirable to use a <tt>std::basic_string</tt> object as a buffer when interoperating with libraries 
that mutate null-terminated arrays of characters. In many cases, these legacy APIs write a null terminator at 
the specified end of the provided buffer. Providing such a function with an appropriately-sized 
<tt>std::basic_string</tt> results in undefined behavior when the <tt>charT</tt> object at the <tt>size()</tt> 
position is overwritten, even if the value remains unchanged.
<p/>
Absent the ability to allow for this, applications are forced into pessimizations such as: providing 
appropriately-sized <tt>std::vectors</tt> of <tt>charT</tt> for interoperating with the legacy API, and then 
copying the <tt>std::vector</tt> to a <tt>std::basic_string</tt>; providing an oversized <tt>std::basic_string</tt> 
object and then calling <tt>resize()</tt> later.
<p/>
A trivial example:
</p>
<blockquote>
<pre>
#include &lt;string&gt;
#include &lt;vector&gt;

void legacy_function(char *out, size_t count) {
  for (size_t i = 0; i &lt; count; ++i) {
    *out++ = '0' + (i % 10);
  }
  *out = '\0'; // <span style="color:#C80000;font-weight:bold">if size() == count, this results in undefined behavior</span>
}

int main() {
  std::string s(10, '\0');
  legacy_function(&amp;s[0], s.size()); // <span style="color:#C80000;font-weight:bold">undefined behavior</span>

  std::vector&lt;char&gt; buffer(11);
  legacy_function(&amp;buffer[0], buffer.size() - 1);
  std::string t(&amp;buffer[0], buffer.size() - 1); // potentially expensive copy

  std::string u(11, '\0');
  legacy_function(&amp;u[0], u.size() - 1);
  u.resize(u.size() - 1); // needlessly complicates the program's logic
}
</pre>
</blockquote>
<p>
A slight relaxation of the requirement on the returned object from the element access operator would 
allow for this interaction with no semantic change to existing programs.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: This should also apply to non-const <tt>data()</tt>. Billy to update wording.</p>
<p>Fri PM: Move to Tentatively Ready</p>


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

<ol>
<li>
<p>Edit 21.3.1.5 [string.access] as indicated:</p>
<blockquote>
<pre>
const_reference operator[](size_type pos) const;
reference operator[](size_type pos);
</pre>
<blockquote>
<p>
-1- <i>Requires</i>: [&hellip;]
<p/>
-2- <i>Returns</i>: <tt>*(begin() + pos)</tt> if <tt>pos &lt; size()</tt>. Otherwise, returns a reference to an object of type
<tt>charT</tt> with value <tt>charT()</tt>, where modifying the object <ins>to any value other than <tt>charT()</tt></ins> 
leads to undefined behavior.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2503" href="#2503">2503.</a> multiline option should be added to <tt>syntax_option_type</tt></h3>
<p><b>Section:</b> 28.5.1 [re.synopt] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Nozomu Kat&#x14d; <b>Opened:</b> 2015-05-22 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.synopt">active issues</a> in [re.synopt].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.synopt">issues</a> in [re.synopt].</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 specification of ECMAScript defines the Multiline property for its
RegExp and the regular expressions ^ and $ behave differently according
to the value of this property. Thus, this property should be available
also in the ECMAScript compatible engine in <tt>std::regex</tt>.
</p>

<p><i>[2015-05-22, Daniel comments]</i></p>

<p>
This issue interacts somewhat with LWG <a href="lwg-active.html#2343">2343</a>.
</p>

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

<p>
Set the priority to match LWG <a href="lwg-active.html#2343">2343</a>.
</p>

<p><i>[2016-08, Chicago]</i></p>

<p>Monday PM: Moved to Tentatively Ready. This also resolves <a href="lwg-active.html#2343">2343</a></p>


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

<ol>
<li><p>Change 28.5.1 [re.synopt] as indicated:</p>

<blockquote><pre>
namespace std::regex_constants {
  typedef T1 syntax_option_type;
  constexpr syntax_option_type icase = <i>unspecified</i> ;
  constexpr syntax_option_type nosubs = <i>unspecified</i> ;
  constexpr syntax_option_type optimize = <i>unspecified</i> ;
  constexpr syntax_option_type collate = <i>unspecified</i> ;
  constexpr syntax_option_type ECMAScript = <i>unspecified</i> ;
  constexpr syntax_option_type basic = <i>unspecified</i> ;
  constexpr syntax_option_type extended = <i>unspecified</i> ;
  constexpr syntax_option_type awk = <i>unspecified</i> ;
  constexpr syntax_option_type grep = <i>unspecified</i> ;
  constexpr syntax_option_type egrep = <i>unspecified</i> ;
  <ins>constexpr syntax_option_type multiline = <i>unspecified</i> ;</ins>
}
</pre></blockquote>
</li>

<li><p>Change 28.5.2 [re.matchflag], Table 138 &mdash; "<tt>syntax_option_type</tt> effects" as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 138 &mdash; <tt>syntax_option_type</tt> effects</caption>
<tr>
<th align="center">Element</th>
<th align="center">Effect(s) if set</th>
</tr>

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

<tr>
<td>
<ins><tt>multiline</tt></ins>
</td>
<td>
<ins>Specifies that <tt>^</tt> shall match the beginning of a line
and <tt>$</tt> shall match the end of a line, if the ECMAScript engine is
selected.</ins>
</td>
</tr>

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

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2510" href="#2510">2510.</a> Tag types should not be <tt>DefaultConstructible</tt></h3>
<p><b>Section:</b> 18.6 [support.dynamic], 20.2 [utility], 20.4.5 [pair.piecewise], 20.10.2 [memory.syn], 20.10.6 [allocator.tag], 30.4 [thread.mutex] <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-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#support.dynamic">issues</a> in [support.dynamic].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::experimental::optional</tt>, for certain reasons, specifies its <tt>nullopt</tt> type
to not be <tt>DefaultConstructible</tt>. It doesn't do so for its tag type <tt>in_place_t</tt>
and neither does the standard proper for any of its tag types. That turns
out to be very unfortunate, consider the following:
</p>
<blockquote><pre>
#include &lt;memory&gt;
#include &lt;array&gt;

void f(std::array&lt;int, 1&gt;, int) {} // #1
void f(std::allocator_arg_t, int) {} // #2

int main()
{
  f({}, 666); // #3
}
</pre></blockquote>
<p>
The call at #3 is ambiguous. What's even worse is that if the overload #1
is removed, the call works just fine. The whole point of a tag type is that
it either needs to mentioned in a call or it needs to be a forwarded argument,
so being able to construct a tag type like that makes no sense.
<p/>
Making the types have an <em>explicit default constructor</em> might have helped, but 
<a href="http://open-std.org/JTC1/SC22/WG21/docs/cwg_active.html#1518">CWG 1518</a>
is going against that idea.
<p/>
[optional.nullopt]/3 solves this problem for <tt>nullopt</tt>:
</p>
<blockquote>
<p>
Type <tt>nullopt_t</tt> shall not have a default constructor. It shall be a
literal type. Constant <tt>nullopt</tt> shall be initialized with an argument
of literal type.
</p>
</blockquote>

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

<p>
Move to Tentatively Ready.
</p>

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

<p>Move back to Open</p>
<p>JW: The linked Core issue (CWG 1518) gives us a better tool to solve this (explicit default constructors). [The CWG Issue means that an explicit default constructor will no longer match "{}".] JW explains that it's important that tag types cannot be constructed from "{}" (e.g. the allocator tag in the tuple constructors).</p>
<p>WEB: Should we now go back and update our constructors? JW: For tag types, yes.</p>
<p>VV: The guideline is that anything that does not mention the type name explicitly should not invoke an explicit constructor.</p>
<p>Ville will provide wording.</p>
<p>Discussion about pair/tuple's default constructor - should they now be explicit?</p>

<p><i>[2016-01-31]</i></p>

<p>
Ville provides revised wording.
</p>

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

<ol>
<li><p>In 18.6 [support.dynamic]/1, change the header <tt>&lt;new&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct nothrow_t <del>{}</del>; <ins><i>see below</i></ins>
extern const nothrow_t nothrow;
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 18.6 [support.dynamic]/1 (<em>following</em> the header <tt>&lt;new&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>nothrow_t</tt> shall not have a default constructor.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.2 [utility]/2, change the header <tt>&lt;utility&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.3.5, pair piecewise construction</i>
struct piecewise_construct_t <del>{ }</del>; <ins><i>see below</i></ins>
constexpr piecewise_construct_t piecewise_construct{ <ins><i>unspecified</i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 20.2 [utility]/2 (<em>following</em> the header <tt>&lt;utility&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>piecewise_construct_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>piecewise_construct</tt> shall be initialized with an argument of literal type.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.4.5 [pair.piecewise], apply the following edits:</p>

<blockquote><pre>
struct piecewise_construct_t <del>{ }</del>;
constexpr piecewise_construct_t piecewise_construct{ <ins><i>unspecified</i></ins> };
</pre></blockquote>
</li>
<li><p>In 20.10.2 [memory.syn]/1, change the header <tt>&lt;memory&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.7.6, allocator argument tag</i>
struct allocator_arg_t <del>{ }</del>; <ins><i>see below</i></ins>
constexpr allocator_arg_t allocator_arg{ <ins><i>unspecified</i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add a new paragraph after 20.10.2 [memory.syn]/1 (<em>following</em> the header <tt>&lt;memory&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>allocator_arg_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>allocator_arg</tt> shall be initialized with an
argument of literal type.</ins>
</p>
</blockquote>
</li>
<li><p>In 20.10.6 [allocator.tag], apply the following edits:</p>

<blockquote><pre>
namespace std {
  struct allocator_arg_t <del>{ }</del>;
  constexpr allocator_arg_t allocator_arg{ <ins><i>unspecified</i></ins> };
}
</pre></blockquote>
<blockquote class="note">
<p>
Editorial drive-by: <tt>piecewise_construct_t</tt> is written, in 20.4.5 [pair.piecewise] like
</p>
<blockquote><pre>
struct piecewise_construct_t { };
constexpr piecewise_construct_t piecewise_construct{};
</pre></blockquote>
<p>
whereas other tag types such as <tt>allocator_construct_t</tt> are, in e.g.
20.10.6 [allocator.tag], written like
</p>
<blockquote><pre>
namespace std {
  struct allocator_arg_t { };
  constexpr allocator_arg_t allocator_arg{};
}
</pre></blockquote>
<p>
We should decide whether or not to write out the <tt>std</tt> namespace in such
paragraphs. I would suggest not to write it out.
</p>
</blockquote>

</li>
<li><p>In 30.4 [thread.mutex]/1, change the header <tt>&lt;mutex&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct defer_lock_t <del>{ }</del>; <ins><i>see below</i></ins>
struct try_to_lock_t <del>{ }</del>; <ins><i>see below</i></ins>
struct adopt_lock_t <del>{ }</del>; <ins><i>see below</i></ins>

constexpr defer_lock_t defer_lock { <ins><i>unspecified </i></ins> };
constexpr try_to_lock_t try_to_lock { <ins><i>unspecified </i></ins> };
constexpr adopt_lock_t adopt_lock { <ins><i>unspecified </i></ins> };
[&hellip;]
</pre></blockquote>
</li>
<li><p>Add three new paragraphs after [thread.mutex]/1 (<em>following</em> the header <tt>&lt;mutex&gt;</tt> synopsis):</p>

<blockquote>
<p>
<ins>-?- Type <tt>defer_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>defer_lock</tt> shall be initialized with an
argument of literal type.</ins>
<p/>
<ins>-?- Type <tt>try_to_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>try_to_lock</tt> shall be initialized with an
argument of literal type.</ins>
<p/>
<ins>-?- Type <tt>adopt_lock_t</tt> shall not have a default constructor. It shall
be a literal type. Constant <tt>adopt_lock</tt> shall be initialized with an
argument of literal type.</ins>
</p>
</blockquote>

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

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

<p>
AM: should have note about compatibility in Annex C<br/>
HH: like this idiom well enough that I've started using it in my own code<br/>
AM: why are pair and tuple involved here?<br/>
GR: they are the only types which forward explicitness with EXPLICIT<br/>
AM: British spelling of behaviour<br/>
AM: happy to drop my issue about Annex C<br/>
</p>

<p><i>[2016-06 Oulu]</i></p>

<p>This is waiting on Core issue 1518</p>
<p>Saturday: Core 1518 was resolved in Oulu</p>

<p><i>[2016-07 Chicago]</i></p>

<p>This is related to <a href="lwg-active.html#2736">2736</a></p>
<p>Monday PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>In 18.6 [support.dynamic]/1, change the header <tt>&lt;new&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct nothrow_t { <ins>explicit nothrow_t() = default;</ins> };
extern const nothrow_t nothrow;
[&hellip;]
</pre></blockquote>
</li>

<li><p>In 20.2 [utility]/2, change the header <tt>&lt;utility&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.3.5, pair piecewise construction</i>
struct piecewise_construct_t { <ins>explicit piecewise_construct_t() = default;</ins> };
constexpr piecewise_construct_t piecewise_construct{};
[&hellip;]
</pre></blockquote>
</li>

<li><p>In 20.4.2 [pairs.pair], change the class template <tt>pair</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
pair(pair&amp;&amp;) = default;
<ins><i>EXPLICIT</i></ins> constexpr pair();
<i>EXPLICIT</i> constexpr pair(const T1&amp; x, const T2&amp; y);
[&hellip;]
</pre></blockquote>
</li>

<li><p>Around 20.4.2 [pairs.pair] p3, apply the following edits:</p>

<blockquote>
<pre>
<ins><i>EXPLICIT</i></ins> constexpr pair();
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: Value-initializes <tt>first</tt> and <tt>second</tt>.
<p/>
-4- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;first_type&gt;::value</tt> is <tt>true</tt> and 
<tt>is_default_constructible&lt;second_type&gt;::value</tt> is <tt>true</tt>. 
[<i>Note</i>: This
behaviour can be implemented by a constructor template with default template arguments. &mdash; 
<i>end note</i>]
<ins>The constructor is explicit if and only if either <tt>first_type</tt> or <tt>second_type</tt> 
is not implicitly default-constructible. 
[<i>Note</i>: This behaviour can be implemented with a trait 
that checks whether a <tt>const first_type&amp;</tt> or a <tt>const second_type&amp;</tt> can be 
initialized with <tt>{}</tt>. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 20.4.5 [pair.piecewise], apply the following edits:</p>

<blockquote><pre>
struct piecewise_construct_t { <ins>explicit piecewise_construct_t() = default;</ins> };
constexpr piecewise_construct_t piecewise_construct{};
</pre></blockquote>
</li>

<li><p>In 20.5.2 [tuple.tuple], change the class template <tt>tuple</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
<i>// 20.4.2.1, tuple construction</i>
<ins><i>EXPLICIT</i></ins> constexpr tuple();
<i>EXPLICIT</i> constexpr tuple(const Types&amp;...); <i>// only if sizeof...(Types) &gt;= 1</i>
[&hellip;]
</pre></blockquote>
</li>

<li><p>Around 20.5.2.1 [tuple.cnstr] p4, apply the following edits:</p>

<blockquote>
<pre>
<ins><i>EXPLICIT</i></ins> constexpr tuple();
</pre>
<blockquote>
<p>
-4- <i>Effects</i>: Value initializes each element.
<p/>
-5- <i>Remarks</i>: This constructor shall not participate in overload resolution unless 
<tt>is_default_constructible&lt;<i>T<sub>i</sub></i>&gt;::value</tt> is <tt>true</tt> for all <i>i</i>. 
[<i>Note</i>: This
behaviour can be implemented by a constructor template with default template arguments. &mdash; 
<i>end note</i>]
<ins>The constructor is explicit if and only if <tt><i>T<sub>i</sub></i></tt> 
is not implicitly default-constructible for at least one <i>i</i>.
[<i>Note</i>: This behaviour can be implemented with a trait that checks whether
a <tt>const Ti&amp;</tt> can be initialized with <tt>{}</tt>. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 20.10.2 [memory.syn]/1, change the header <tt>&lt;memory&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
// <i>20.7.6, allocator argument tag</i>
struct allocator_arg_t { <ins>explicit allocator_arg_t() = default;</ins> };
constexpr allocator_arg_t allocator_arg{};
[&hellip;]
</pre></blockquote>
</li>

<li><p>In 20.10.6 [allocator.tag], apply the following edits:</p>

<blockquote><pre>
namespace std {
  struct allocator_arg_t { <ins>explicit allocator_arg_t() = default;</ins> };
  constexpr allocator_arg_t allocator_arg{};
}
</pre></blockquote>
<blockquote class="note">
<p>
Editorial drive-by: <tt>piecewise_construct_t</tt> is written, in 20.4.5 [pair.piecewise] like
</p>
<blockquote><pre>
struct piecewise_construct_t { };
constexpr piecewise_construct_t piecewise_construct{};
</pre></blockquote>
<p>
whereas other tag types such as <tt>allocator_construct_t</tt> are, in e.g.
20.10.6 [allocator.tag], written like
</p>
<blockquote><pre>
namespace std {
  struct allocator_arg_t { };
  constexpr allocator_arg_t allocator_arg{};
}
</pre></blockquote>
<p>
We should decide whether or not to write out the <tt>std</tt> namespace in such
paragraphs. I would suggest not to write it out.
</p>
</blockquote>
</li>

<li><p>In 30.4 [thread.mutex]/1, change the header <tt>&lt;mutex&gt;</tt> synopsis:</p>

<blockquote><pre>
[&hellip;]
struct defer_lock_t { <ins>explicit defer_lock_t() = default;</ins> };
struct try_to_lock_t { <ins>explicit try_to_lock_t() = default;</ins> };
struct adopt_lock_t { <ins>explicit adopt_lock_t() = default;</ins> };

constexpr defer_lock_t defer_lock { };
constexpr try_to_lock_t try_to_lock { };
constexpr adopt_lock_t adopt_lock { };
[&hellip;]
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2514" href="#2514">2514.</a> Type traits must not be <tt>final</tt></h3>
<p><b>Section:</b> 20.15.1 [meta.rqmts] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2015-07-03 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
We should make it clear that all standard <tt>UnaryTypeTraits</tt>,
<tt>BinaryTypeTraits</tt> and <tt>TransformationTraits</tt> are not <tt>final</tt>.
<p/>
Otherwise it is not safe to use them as arguments to a template like this:
</p>
<blockquote><pre>
template&lt;typename C1, typename C2&gt;
struct conjunction
  : conditional_t&lt;C1::value, C2, C1&gt;
{ };
</pre></blockquote>

<p><i>[2016-08-03 Chicago LWG]</i></p>

<p>
Walter, Nevin, and Jason provide initial Proposed Resolution.
</p>

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

<ol>
<li><p>Change 20.15.1 [meta.rqmts] as indicated:</p>

<blockquote>
<p>
-1- A <em>UnaryTypeTrait</em> describes a property of a type. It shall be a <ins>non-<code>final</code></ins> 
class template [&hellip;]
<p/>
-2- A <em>BinaryTypeTrait</em> describes a relationship between two types. It shall be a 
<ins>non-<code>final</code></ins> class template [&hellip;]
<p/>
-3- A <em>TransformationTrait</em> modifies a property of a type. It shall be a 
<ins>non-<code>final</code></ins> class template [&hellip;]
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-04 Chicago LWG]</i></p>

<p>
LWG discusses and expresses preference for a more general, Library-wide, resolution. Walter and Nevin 
provide a new Proposed Resolution consistent with such guidance.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Add a new paragraph add the end of 17.6.5.11 [derivation] as indicated:</p>

<blockquote>
<p>
<ins>-?- All types specified in the C++ standard library shall be non-<code>final</code>
types unless otherwise specified.</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2519" href="#2519">2519.</a> Iterator <tt>operator-=</tt> has gratuitous undefined behaviour</h3>
<p><b>Section:</b> 24.2.7 [random.access.iterators] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hubert Tong  <b>Opened:</b> 2015-07-15 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#random.access.iterators">issues</a> in [random.access.iterators].</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 subclause 24.2.7 [random.access.iterators], Table 110, the operational semantics for the expression "<tt>r -= n</tt>" 
are defined as
</p>
<blockquote><pre>
return r += -n;
</pre></blockquote>
<p>
Given a <tt>difference_type</tt> of a type <tt>int</tt> with range [-32768, 32767], if the value of <tt>n</tt> is -32768, 
then the evaluation of <tt>-n</tt> causes undefined behaviour (Clause 5 [expr] paragraph 4).
<p/>
The operational semantics may be changed such that the undefined behaviour is avoided.
<p/>
<b>Suggested wording:</b>
<p/>
Replace the operational semantics for "<tt>r -= n</tt>" with:
</p>
<blockquote><pre>
{ 
  difference_type m = n;
  if (m >= 0)
    while (m--)
      --r;
  else
    while (m++)
      ++r;
  return r; 
}
</pre></blockquote>
<p>
Jonathan Wakely:
<p/>
I'm now convinced we <em>don't</em> want to change the definition of <tt>-=</tt> and
instead we should explicitly state the (currently implicit)
precondition that <tt>n != numeric_limits&lt;difference_type&gt;::min()</tt>.
</p>

<p><i>[2016-08, Chicago]</i></p>

<p>Monday PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change Table 110 "Random access iterator requirements (in addition to
bidirectional iterator)" as indicated:</p>
<blockquote>
<table border="1">
<caption>Table 110 &mdash; Random access iterator requirements (in addition to
bidirectional iterator)</caption>
<tr>
<th align="center">Expression</th>
<th align="center">Return type</th>
<th align="center">Operational<br/>semantics</th>
<th align="center">Assertion&#47;note<br/>pre-&#47;post-condition</th>
</tr>

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

<tr>
<td>
<tt>r -= n</tt>
</td>

<td>
<tt>X&amp;</tt>
</td>

<td>
<tt>return r += -n;</tt>
</td>

<td>
<ins>pre: the absolute value of <tt>n</tt> is in the range of representable values of <tt>difference_type</tt>.</ins>
</td>
</tr>

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

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





<hr>
<h3><a name="2531" href="#2531">2531.</a> <tt>future::get</tt> should explicitly state that the shared state is released</h3>
<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2015-09-03 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</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 standard is usually very explicit on when a shared state is released, except for <tt>future::get</tt> 
for which it only states <tt>valid() == false</tt> as a postcondition.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Modify 30.6.6 [futures.unique_future] as indicated:</p>
<blockquote><pre>
R future::get();
R&amp; future&lt;R&amp;&gt;::get();
void future&lt;void&gt;::get();
</pre>
<blockquote>
<p>
-14- <i>Note</i>: as described above, the template and its two required specializations differ only in the return
type and return value of the member function <tt>get</tt>.
<p/>
-15- <i>Effects</i>:
</p>
<ul>
<li><p><tt>wait()</tt>s until the shared state is ready, then retrieves the value stored in the shared state<del>.</del><ins>;</ins></p></li>
<li><p><ins>releases any shared state (30.6.4 [futures.state]).</ins></p></li>
</ul>
<p>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2534" href="#2534">2534.</a> Constrain rvalue stream operators</h3>
<p><b>Section:</b> 27.7.3.9 [ostream.rvalue], 27.7.2.6 [istream.rvalue] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Robert Haberlach <b>Opened:</b> 2015-09-08 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#ostream.rvalue">active issues</a> in [ostream.rvalue].</p>
<p><b>View all other</b> <a href="lwg-index.html#ostream.rvalue">issues</a> in [ostream.rvalue].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The rvalue stream insertion and extraction operators should be constrained to not participate in overload 
resolution unless the expression they evaluate is well-formed. Programming code that tests the validity of 
stream insertions (or extractions) using SFINAE can result in false positives, as the present 
declarations accept virtually any right-hand side argument. Moreover, there is no need for pollution of 
the candidate set with ill-formed specializations.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Modify 27.7.3.9 [ostream.rvalue] as indicated:</p>
<blockquote>
<pre>
template &lt;class charT, class traits, class T&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
  operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp;&amp; os, const T&amp; x);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: <tt>os &lt;&lt; x</tt>
<p/>
-2- <i>Returns</i>: <tt>os</tt>
<p/>
<ins>-?- <i>Remarks</i>: This function shall not participate in overload resolution unless the expression 
<tt>os &lt;&lt; x</tt> is well-formed.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 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; x);
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: <tt>is &gt;&gt; x</tt>
<p/>
-2- <i>Returns</i>: <tt>is</tt>
<p/>
<ins>-?- <i>Remarks</i>: This function shall not participate in overload resolution unless the expression 
<tt>is &gt;&gt; x</tt> is well-formed.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2536" href="#2536">2536.</a> What should <tt>&lt;complex.h&gt;</tt> do?</h3>
<p><b>Section:</b> D.4 [depr.c.headers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2015-09-10 <b>Last modified:</b> 2016-09-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View all other</b> <a href="lwg-index.html#depr.c.headers">issues</a> in [depr.c.headers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG issue <a href="lwg-defects.html#1134">1134</a> removed the resolution of LWG <a href="lwg-defects.html#551">551</a>, leaving an incorrect specification for 
the behavior of <tt>&lt;complex.h&gt;</tt>. This header is currently required to make <tt>std::complex</tt> (and 
associated functions) visible in the global namespace, but should not be so required.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Add a new paragraph <em>before</em> D.4 [depr.c.headers]/2:</p>
<blockquote><p>
<ins>-?- The header <tt>&lt;complex.h&gt;</tt> behaves as if it simply includes the header <tt>&lt;ccomplex&gt;</tt>.</ins>
</p></blockquote>
</li>

<li><p>Change in D.4 [depr.c.headers]/2:</p>
<blockquote><p>
-2- Every <ins>other</ins> C header, each of which has a name of the form <tt>name.h</tt>, behaves as if each name placed 
in the standard library namespace by the corresponding <tt>cname</tt> header is placed within the global namespace scope. 
It is unspecified whether these names are first declared or defined within namespace scope (3.3.6) of the namespace
<tt>std</tt> and are then injected into the global namespace scope by explicit <i>using-declarations</i> (7.3.3).
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2540" href="#2540">2540.</a> <tt>unordered_multimap::insert</tt> hint iterator</h3>
<p><b>Section:</b> 23.2.5 [unord.req] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Isaac Hier <b>Opened:</b> 2015-09-16 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
I have been wondering about the C++ standard requirements regarding the hint iterator for insertion into an 
<tt>unordered_multimap</tt> (and I imagine a similar question could be asked of <tt>unordered_map</tt>, but 
I have not researched that topic). As far as I can tell, it seems perfectly valid for an implementation to 
allow only valid dereferencable iterators to be used as the hint argument for this member function. If that 
is correct, it means that one could not expect the end iterator to be used as a valid hint nor could one use 
the begin iterator of an empty <tt>unordered_multimap</tt> as the hint. However, this essentially precludes 
all uses of inserter on an empty <tt>unordered_multimap</tt> seeing as the inserter functor requires that a 
hint iterator be passed to its constructor.
<p/>
Howard Hinnant:
</p>
<blockquote class="note">
<p>
The intent of the standard is that the iterator produced from container <tt>c</tt> by <tt>c.end()</tt> is a 
valid (but non-dereferenceable) iterator into container <tt>c</tt>. It is reachable by every other iterator 
into <tt>c</tt>.
<p/>
It appears to me that you and the Bloomberg implementation have fallen victim to a type-o in the Unordered 
associative container requirements, Table 102.  The row containing:
</p>
<blockquote><pre>
a.insert(q, t);
</pre></blockquote>
<p>
should read instead:
</p>
<blockquote><pre>
a.insert(p, t);
</pre></blockquote>
<p>
The distinction is that <tt>p</tt> is valid, and <tt>q</tt> is both valid and dereferenceable.
The correction of this type-o would make unordered container <tt>insert</tt> consistent with unordered <tt>emplace_hint</tt>, 
associative <tt>insert</tt>, and associative <tt>emplace_hint</tt>.
</p>
</blockquote>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
Change the insert-with-hint row in Table 102
Unordered associative container requirements like so:
</p>
<blockquote>
<table border="1" cellpadding="4"><tr>
<td><tt>a.insert(<del>q</del><ins>p</ins>, t);</tt><br/></td>
<td><tt>iterator</tt><br/></td>
<td><i>Requires:</i> If <tt>t</tt> is a non-const<br/>...</td>
<td>Average Case<br/>...</td>
</tr></table>
</blockquote>





<hr>
<h3><a name="2543" href="#2543">2543.</a> LWG 2148 (hash support for enum types) seems under-specified</h3>
<p><b>Section:</b> 20.14.14 [unord.hash] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2015-09-27 <b>Last modified:</b> 2016-09-11</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#unord.hash">active issues</a> in [unord.hash].</p>
<p><b>View all other</b> <a href="lwg-index.html#unord.hash">issues</a> in [unord.hash].</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 rationale in issue <a href="lwg-defects.html#2148">2148</a> says:
</p>
<blockquote class="note"><p>
This proposed resolution doesn't specify anything else about the
primary template, allowing implementations to do whatever they want
for non-enums: <tt>static_assert</tt> nicely, explode horribly at compiletime
or runtime, etc.
</p></blockquote>
<p>
libc++ seems to implement it by defining the primary template and
<tt>static_assert</tt>ing <tt>is_enum</tt> inside it. However, that brings forth
a problem; there are reasonable SFINAE uses broken by it:
</p>
<blockquote><pre>
#include &lt;type_traits&gt;
#include &lt;functional&gt;

class S{}; // No hash specialization

template&lt;class T&gt;
auto f(int) -&gt; decltype(std::hash&lt;T&gt;(), std::true_type());

template&lt;class T&gt;
auto f(...) -&gt; decltype(std::false_type());

static_assert(!decltype(f&lt;S&gt;(0))::value, "");
</pre></blockquote>
<p>
MSVC doesn't seem to accept that code either.
<p/>
There <em>is</em> a way to implement LWG <a href="lwg-defects.html#2148">2148</a> so that <tt>hash</tt> for enums is supported
without breaking that sort of SFINAE uses:
</p>
<ol>
<li><p>Derive the main <tt>hash</tt> template from a library-internal uglified-named
base template that takes a type and a <tt>bool</tt>, pass as argument for the base
the result of <tt>is_enum</tt>.</p></li>
<li><p>Partially specialize that base template so that the false-case has
a suitable set of private special member function declarations so that it's not
an aggregate nor usable in almost any expression.</p></li>
</ol>

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

<p>EricWF to come back with wording; move to Open</p>

<p><i>[2016-05-08, Eric Fiselier &amp; Ville provide wording]</i></p>


<p><i>[2016-05-25, Tim Song comments]</i></p>

<p>
I see two issues with this P/R:
</p>
<ol>
<li><p>
"for which neither the library nor the user provides an explicit specialization" should probably be "for which neither 
the library nor the user provides an explicit or partial specialization".
</p></li>
<li><p>
Saying that the specialization "is not <tt>DefaultConstructible</tt> nor <tt>MoveAssignable</tt>" is not enough to 
guarantee that common SFINAE uses will work. Both of those requirements have several parts, and it's not too hard 
to fail only some of them. For instance, not meeting the assignment postcondition breaks <tt>MoveAssignable</tt>, 
but is usually not SFINAE-detectible. And for <tt>DefaultConstructible</tt>, it's easy to write something in a way 
that breaks <tt>T()</tt> but not <tt>T{}</tt> (due to aggregate initialization in the latter case).
</p></li>
</ol>

<p><i>[2016-06-14, Daniel comments]</i></p>

<p>
The problematic part of the P/R is that it describes constraints that would be suitable if they were constraints 
for user-code, but they are not suitable as requirements imposed on implementations to provide certain guarantees 
for clients of the Library. The guarantees should be written in terms of testable compile-time expressions, e.g. based on 
negative results of <tt>is_default_constructible&lt;hash&lt;X&gt;&gt;::value</tt>, 
<tt>std::is_copy_constructible&lt;hash&lt;X&gt;&gt;::value</tt>, and possibly also 
<tt>std::is_destructible&lt;hash&lt;X&gt;&gt;::value</tt>. <em>How</em> an implementation realizes these negative 
results shouldn't be specified, though, but the expressions need to be well-formed and well-defined.

<p><i>[2016-08-03, Ville provides revised wording as response to Daniel's previous comment]</i></p>

</p>

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

<ol>
<li><p>Insert a new paragraph after 20.14.14 [unord.hash]/2</p>

<blockquote>
<p>
-2- The template specializations shall meet the requirements of class template <tt>hash</tt> (20.12.14).
<p/>
<ins>-?- For any type that is not of integral or enumeration type, or for
which neither the library nor the user provides an explicit
specialization of the class template <tt>hash</tt>, the specialization of <tt>hash</tt> does not meet
any of the <tt>Hash</tt> requirements, and is not <tt>DefaultConstructible</tt> nor
<tt>MoveAssignable</tt>.
[<i>Note</i>: this means that the specialization of <tt>hash</tt> exists, but any
attempts to use it as a Hash will be ill-formed. &mdash; <i>end note</i>]
</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>

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

<ol>
<li><p>Insert a new paragraph after 20.14.14 [unord.hash]/2</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> I see no reason to specify whether <tt>H&lt;T&gt;</tt> is
destructible. There's no practical use case for which that would need to be covered. 
libstdc++ makes it so that <tt>H&lt;T&gt;</tt> is destructible.]
</p>
</blockquote>

<blockquote>
<p>
-2- The template specializations shall meet the requirements of class template <tt>hash</tt> (20.12.14).
<p/>
<ins>-?- For any type <tt>T</tt> that is not of integral or enumeration type, or for
which neither the library nor the user provides an explicit or partial specialization of the class
template hash, the specialization of <tt>hash&lt;T&gt;</tt> has the following properties:
</ins>
</p>
<ul>
<li><ins><tt>is_default_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_copy_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_move_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_copy_assignable_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_move_assignable_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_callable_v&lt;hash&lt;T&gt;, T&amp;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_callable_v&lt;hash&lt;T&gt;, const T&amp;&gt;</tt> is <tt>false</tt></ins></li>
</ul>
<p>
<ins>[<i>Note:</i> this means that the specialization of <tt>hash</tt> exists, but any
attempts to use it as a <tt>Hash</tt> will be ill-formed. &mdash; end note]</ins>
</p>
</blockquote>
</li>
</ol></blockquote>

<p><i>[2016-08-09 Daniel reopens]</i></p>

<p>
As pointed out by Eric, the usage of <tt>is_callable</tt> is incorrect.
Eric provides new wording.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Insert a new paragraph after 20.14.14 [unord.hash]/2</p>

<blockquote class="note">
<p>
[<i>Drafting note:</i> I see no reason to specify whether <tt>H&lt;T&gt;</tt> is
destructible. There's no practical use case for which that would need to be covered. 
libstdc++ makes it so that <tt>H&lt;T&gt;</tt> is destructible.]
</p>
</blockquote>

<blockquote>
<p>
-2- The template specializations shall meet the requirements of class template <tt>hash</tt> (20.12.14).
<p/>
<ins>-?- For any type <tt>T</tt> that is not of integral or enumeration type, or for
which neither the library nor the user provides an explicit or partial specialization of the class
template hash, the specialization of <tt>hash&lt;T&gt;</tt> has the following properties:
</ins>
</p>
<ul>
<li><ins><tt>is_default_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_copy_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_move_constructible_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_copy_assignable_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>is_move_assignable_v&lt;hash&lt;T&gt;&gt;</tt> is <tt>false</tt></ins></li>
<li><ins><tt>hash&lt;T&gt;</tt> is not a function object type (20.14 [function.objects])</ins></li>
</ul>
<p>
<ins>[<i>Note:</i> this means that the specialization of <tt>hash</tt> exists, but any
attempts to use it as a <tt>Hash</tt> will be ill-formed. &mdash; end note]</ins>
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2544" href="#2544">2544.</a> <tt>istreambuf_iterator(basic_streambuf&lt;charT, traits&gt;* s)</tt> effects unclear when <tt>s</tt> is <tt>0</tt></h3>
<p><b>Section:</b> 24.6.3.2 [istreambuf.iterator.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> S. B. Tam <b>Opened:</b> 2015-10-05 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</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>
N4527 24.6.3.2 [istreambuf.iterator.cons] does not mention what the effect of calling 
<tt>istreambuf_iterator(basic_streambuf&lt;charT, traits&gt;* s)</tt> is when <tt>s</tt> is a null pointer. 
It should be made clear that this case is well-formed and the result is a end-of-stream iterator.
<p/>
Daniel:
<p/>
According to 24.6.3 [istreambuf.iterator] p1:
</p>
<blockquote><p>
[&hellip;] The default constructor <tt>istreambuf_iterator()</tt> and the constructor <tt>istreambuf_iterator(0)</tt> both 
construct an end-of-stream iterator object suitable for use as an end-of-range. [&hellip;]
</p></blockquote>
<p>
This indicates that the described constructor creates an end-of-stream iterator, but this wording is part of the introductory 
wording and I recommend to make 24.6.3.2 [istreambuf.iterator.cons] clearer, because the existing specification is already
flawed, e.g. it never specifies when and how the exposition-only-member <tt>sbuf_</tt> is initialized. The proposed wording 
below attempts to solve these problems as well.
</p>

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

<ol>
<li>
<p>Change 24.6.3.2 [istreambuf.iterator.cons] as indicated:
<p/>
[<i>Editorial note</i>: The proposed wording changes also performs some editorial clean-up of the existing mismatches
of the declarations in the class template synopsis and the individual member specifications. The below wording intentionally
does not say anything about the concrete value of <tt>sbuf_</tt> for end-of-stream iterator values, because that
was never specified before; in theory, this could be some magic non-null pointer that can be used in constant expressions. 
But the wording could be drastically simplified by requiring <tt>sbuf_</tt> to be a null pointer for an end-of-stream iterator value, 
since I have not yet seen any implementation where this requirement does not hold. &mdash; <i>end editorial note</i>]
</p>
<blockquote>
<pre>
constexpr istreambuf_iterator() noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: Constructs the end-of-stream iterator.
</p>
</blockquote>
<pre>
istreambuf_iterator(<del>basic_istream&lt;charT,traits&gt;</del><ins>istream_type</ins>&amp; s) noexcept;
<del>istreambuf_iterator(basic_streambuf&lt;charT,traits&gt;* s) noexcept;</del>
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: <ins>If <tt>s.rdbuf()</tt> is a null pointer, constructs an end-of-stream iterator; otherwise 
initializes  <tt>sbuf_</tt> with <tt>s.rdbuf()</tt> and constructs an <tt>istreambuf_iterator</tt> that uses the 
<tt>streambuf_type</tt> object <tt>*sbuf_</tt></ins><del>Constructs an <tt>istreambuf_iterator&lt;&gt;</tt> that 
uses the <tt>basic_streambuf&lt;&gt;</tt> object <tt>*(s.rdbuf())</tt>, or <tt>*s</tt>, respectively. Constructs 
an end-of-stream iterator if <tt>s.rdbuf()</tt> is null</del>.
</p>
</blockquote>
<pre>
<ins>istreambuf_iterator(streambuf_type* s) noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: If <tt>s</tt> is a null pointer, constructs an end-of-stream iterator; otherwise initializes 
<tt>sbuf_</tt> with <tt>s</tt> and constructs an <tt>istreambuf_iterator</tt> that uses the <tt>streambuf_type</tt> 
object <tt>*sbuf_</tt>.</ins>
</p>
</blockquote>
<pre>
istreambuf_iterator(const proxy&amp; p) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: <ins>Initializes <tt>sbuf_</tt> with <tt>p.sbuf_</tt> and constructs an <tt>istreambuf_iterator</tt> 
that uses the <tt>streambuf_type</tt> object <tt>*sbuf_</tt></ins><del>Constructs a <tt>istreambuf_iterator&lt;&gt;</tt> 
that uses the <tt>basic_streambuf&lt;&gt;</tt> object pointed to by the <tt>proxy</tt> object's constructor argument 
<tt>p</tt></del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2015-10-20, Daniel provides alternative wording]</i></p>


<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


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

<ol>
<li>
<p>Change 24.6.3.2 [istreambuf.iterator.cons] as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: The proposed wording changes also performs some editorial clean-up of the existing mismatches
of the declarations in the class template synopsis and the individual member specifications. The below wording is 
simplified by requiring <tt>sbuf_</tt> to be a null pointer for an end-of-stream iterator value, 
since I have not yet seen any implementation where this requirement does not hold. Even if there <em>were</em> such an 
implementation, this would still be conforming, because concrete exposition-only member values are not part of public 
API. &mdash; <i>end drafting note</i>]
</p>
</blockquote>
<blockquote>
<p>
<ins>For each <tt>istreambuf_iterator</tt> constructor in this section, an end-of-stream iterator is 
constructed if and only if the exposition-only member <tt>sbuf_</tt> is initialized with a null 
pointer value.</ins>
</p>
<pre>
constexpr istreambuf_iterator() noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects</i>: <ins>Initializes <tt>sbuf_</tt> with <tt>nullptr</tt></ins><del>Constructs the end-of-stream iterator</del>.
</p>
</blockquote>
<pre>
istreambuf_iterator(<del>basic_istream&lt;charT,traits&gt;</del><ins>istream_type</ins>&amp; s) noexcept;
<del>istreambuf_iterator(basic_streambuf&lt;charT,traits&gt;* s) noexcept;</del>
</pre>
<blockquote>
<p>
-2- <i>Effects</i>: <ins>Initializes <tt>sbuf_</tt> with <tt>s.rdbuf()</tt></ins><del>Constructs 
an <tt>istreambuf_iterator&lt;&gt;</tt> that uses the <tt>basic_streambuf&lt;&gt;</tt> object 
<tt>*(s.rdbuf())</tt>, or <tt>*s</tt>, respectively. Constructs 
an end-of-stream iterator if <tt>s.rdbuf()</tt> is null</del>.
</p>
</blockquote>
<pre>
<ins>istreambuf_iterator(streambuf_type* s) noexcept;</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects</i>: Initializes <tt>sbuf_</tt> with <tt>s</tt>.</ins>
</p>
</blockquote>
<pre>
istreambuf_iterator(const proxy&amp; p) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Effects</i>: <ins>Initializes <tt>sbuf_</tt> with <tt>p.sbuf_</tt></ins><del>Constructs a <tt>istreambuf_iterator&lt;&gt;</tt> 
that uses the <tt>basic_streambuf&lt;&gt;</tt> object pointed to by the <tt>proxy</tt> object's constructor argument 
<tt>p</tt></del>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2556" href="#2556">2556.</a> Wide contract for <tt>future::share()</tt></h3>
<p><b>Section:</b> 30.6.6 [futures.unique_future] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2015-11-05 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.unique_future">active issues</a> in [futures.unique_future].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.unique_future">issues</a> in [futures.unique_future].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>future::share()</tt> is not <tt>noexcept</tt>, it has a narrow contact requiring <tt>valid()</tt> as per the blanket 
wording in 30.6.6 [futures.unique_future] p3. Its effects, however, are <tt>return shared_future&lt;R&gt;(std::move(*this))</tt>, 
which is <tt>noexcept</tt> as it has a wide contract. If the source <tt>future</tt> isn't valid then the target 
<tt>shared_future</tt> simply won't be valid either. There appears to be no technical reason preventing <tt>future::share()</tt> 
from having a wide contract, and thus being <tt>noexcept</tt>.
</p>

<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 30.6.6 [futures.unique_future] as indicated:</p>

<blockquote>
<p>
-3- The effect of calling any member function other than the destructor, the move-assignment operator, <ins><tt>share</tt>,</ins> 
or <tt>valid</tt> on a <tt>future</tt> object for which <tt>valid() == false</tt> is undefined. [<i>Note</i>: Implementations 
are encouraged to detect this case and throw an object of type <tt>future_error</tt> with an error condition of 
<tt>future_errc::no_state</tt>. &mdash; <i>end note</i>]
</p>
<blockquote><pre>
namespace std {
  template &lt;class R&gt;
  class future {
  public:
    [&hellip;]
    shared_future&lt;R&gt; share() <ins>noexcept</ins>;
    [&hellip;]
  };
}
</pre></blockquote>
<p>
[&hellip;]
</p>
<pre>
shared_future&lt;R&gt; share() <ins>noexcept</ins>;
</pre>
<blockquote>
<p>
-12- <i>Returns</i>: <tt>shared_future&lt;R&gt;(std::move(*this))</tt>.
<p/>
-13- <i>Postcondition</i>: <tt>valid() == false</tt>.
</p>
</blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2562" href="#2562">2562.</a> Consistent total ordering of pointers by comparison functors</h3>
<p><b>Section:</b> 20.14.6 [comparisons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2015-11-18 <b>Last modified:</b> 2016-08-05</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#comparisons">active issues</a> in [comparisons].</p>
<p><b>View all other</b> <a href="lwg-index.html#comparisons">issues</a> in [comparisons].</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>
N4567 20.14.6 [comparisons]/14 specifies that the comparison functors provide a total ordering for pointer types:
</p>
<blockquote><p>
For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations for 
any pointer type yield a total order, even if the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt> 
do not.
</p></blockquote>
<p>
It notably does not specify:
</p>
<ul>
<li><p>whether the specializations of all of the named templates for a given pointer type yield the <em>same</em> total order</p></li>
<li><p>whether the total order imposed respects the partial order imposed by the built-in operators</p></li>
<li><p>whether the total order imposed is consistent with the partition induced by <tt>==</tt></p></li>
</ul>
<p>
All of which are important for sane semantics and provided by common implementations, since the built-in operators provide 
a total order and the comparison functors yield that same order.
<p/>
It would be extremely confusing &mdash; if not outright insane &mdash; for e.g.:
</p>
<ul>
<li><p><tt>less&lt;int*&gt;</tt> and <tt>greater&lt;int*&gt;</tt> to yield different orders</p></li>
<li><p><tt>less&lt;int*&gt;</tt> to disagree with <tt>&lt;</tt> on the relative order of two pointers for which <tt>&lt;</tt> 
is defined</p></li>
<li><p><tt>less&lt;int*&gt;</tt> to order <tt>a</tt> before <tt>b</tt> when <tt>a == b</tt>, i.e., not preserve equality.</p></li>
</ul>
<p>
Consistent semantics for the various comparison functors and the built-in operators is so intuitive as to be assumed by most programmers.
<p/>
Related issues: <a href="lwg-defects.html#2450">2450</a>, <a href="lwg-active.html#2547">2547</a>.
</p>

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

<ol>
<li><p>Alter 20.14.6 [comparisons]/14 to read:</p>
<blockquote><p>
For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the specializations for any pointer type
yield <del>a</del><ins>the same</ins> total order, even if the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, 
<tt>&gt;=</tt> do not. <ins>The total order shall respect the partial order imposed by the built-in operators.</ins>
</p></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-05-20, Casey Carter comments and suggests revised wording]</i></p>

<p>
The new proposed wording is attempting to address the issue raised in the 2016-02-04 telecon.
<p/>
The real issue I'm trying to address here is ensure that "weird" implementations provide the same kind of consistency 
for pointer orderings as "normal" implementations that use a flat address spaces and have totally ordered <tt>&lt;</tt>. 
If <tt>a &lt; b</tt> is true for <tt>int</tt> pointers <tt>a</tt> and <tt>b</tt>, then <tt>less&lt;int*&gt;(a, b)</tt>, 
<tt>less_equal&lt;int*&gt;(a, b)</tt>, <tt>less&lt;char*&gt;(a, b)</tt>, <tt>less&lt;void*&gt;(a, b)</tt>, and 
<tt>greater&lt;int*&gt;(b, a)</tt> should all hold. I <em>think</em> this wording is sufficient to provide that.
</p>

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

<ol>
<li><p>Alter 20.14.6 [comparisons] to read:</p>
<blockquote><p>
-14- For templates <tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and <tt>less_equal</tt>, the 
specializations for any pointer type yield <del>a</del><ins>the same</ins> total order<ins>. That total order is 
consistent with the partial order imposed by</ins><del>, even if</del> the built-in operators <tt>&lt;</tt>, <tt>&gt;</tt>, 
<tt>&le;</tt>, <ins>and</ins> <tt>&gt;</tt> <del>do not</del>. <ins>[<i>Note</i>: When <tt>a &lt; b</tt> is 
well-defined for pointers <tt>a</tt> and <tt>b</tt> of type <tt>P</tt>, this implies <tt>(a &lt; b) == 
less&lt;P&gt;(a, b)</tt>, <tt>(a &gt; b) == greater&lt;P&gt;(a, b)</tt>, and so forth. &mdash; <i>end note</i>]</ins> 
For template specializations <tt>greater&lt;void&gt;</tt>, <tt>less&lt;void&gt;</tt>, <tt>greater_equal&lt;void&gt;</tt>, 
and <tt>less_equal&lt;void&gt;</tt>, if the call operator calls a built-in operator comparing pointers, the 
call operator yields a total order.
</p></blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-04 Chicago LWG]</i></p>

<p>
LWG discusses and concludes that we are trying to accomplish the following:
</p>
<ol>
<li>
<blockquote><pre>
T* a = /* ... */;
T* b = /* ... */;
</pre></blockquote>
<p>
 if <tt>a &lt; b</tt> is valid, <tt>a &lt; b == less&lt;T*&gt;(a, b)</tt>, and analogously for <tt>&gt;</tt>, 
 <tt>&lt;=</tt>, <tt>&gt;=</tt>.
</p>
</li>
<li>
<blockquote><pre>
less&lt;void&gt;(a, b) == less&lt;T*&gt;(a, b);
less&lt;T*&gt;(a, b) == greater&lt;T*&gt;(b, a);
</pre></blockquote>
<p>
etc.
</p>
</li>
<li><p>
<tt>less&lt;T*&gt;</tt> produces a strict total ordering with which the other three
function objects are consistent
</p></li>
<li><p>
<tt>less&lt;void&gt;</tt> when applied to pointers produces a strict total ordering with
which the other three are consistent
</p></li>
<li><p>
<tt>less&lt;void&gt;</tt> when applied to pointers of the same type produces the same
strict total ordering as <tt>less&lt;T*&gt;</tt>, and analogously for the other three
</p></li>
<li><p>
we are not addressing <tt>less&lt;void&gt;</tt> (and the other three) when applied to
pointers of differing types
</p></li>
</ol>
<p>
Walter and Nevin revise Proposed Wording accordingly.
</p>
<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 20.14.6 [comparisons] p14 as indicated:</p>
<blockquote><p>
-14- For templates <del><tt>greater</tt>, <tt>less</tt>, <tt>greater_equal</tt>, and 
<tt>less_equal</tt></del><ins><ins><tt>less</tt>, <tt>greater</tt>, <tt>less_equal</tt>,
and <tt>greater_equal</tt></ins></ins>, 
the specializations for any pointer type yield a <ins>strict</ins> total order<ins>
that is consistent among those specializations and is also consistent with the partial order imposed by</ins>
<del>, even if</del> the built-in operators 
<tt>&lt;</tt>, <tt>&gt;</tt>, <tt>&lt;=</tt>, <tt>&gt;=</tt> <del>do not</del>. <ins>[<i>Note:</i>
When <tt>a &lt; b</tt> is well-defined for pointers <tt>a</tt> and <tt>b</tt> of type <tt>P</tt>,
this implies <tt>(a &lt; b) == less&lt;P&gt;(a, b)</tt>, <tt>(a &gt; b) == greater&lt;P&gt;(a, b)</tt>,
and so forth. &mdash; <i>end note</i>]</ins> For template specializations 
<del><tt>greater&lt;void&gt;</tt>, <tt>less&lt;void&gt;</tt>, <tt>greater_equal&lt;void&gt;</tt>, and 
<tt>less_equal&lt;void&gt;</tt></del><ins><tt>less&lt;void&gt;</tt>, <tt>greater&lt;void&gt;</tt>,
<tt>less_equal&lt;void&gt;</tt>, and <tt>greater_equal&lt;void&gt;</tt></ins>, if the call operator 
calls a built-in operator comparing pointers, the call operator yields a <ins>strict</ins> total 
order <ins>that is consistent among those specializations and is also consistent
with the partial order imposed by those built-in operators</ins>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2567" href="#2567">2567.</a> Specification of logical operator traits uses <tt>BaseCharacteristic</tt>, which is defined only for <tt>UnaryTypeTraits</tt> 
and <tt>BinaryTypeTraits</tt></h3>
<p><b>Section:</b> 20.15.8 [meta.logical] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-10 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.logical">active issues</a> in [meta.logical].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.logical">issues</a> in [meta.logical].</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 specification of <tt>conjunction</tt> and <tt>disjunction</tt> uses the term <tt>BaseCharacteristic</tt>, which 
is problematic in several ways:
</p>
<ul>
<li><p>That term is defined in 20.15.1 [meta.rqmts], but only for <tt>UnaryTypeTraits</tt> and <tt>BinaryTypeTraits</tt>. 
<tt>conjunction</tt> and <tt>disjunction</tt> seem to be neither.</p></li>
<li><p>20.15.1 [meta.rqmts] also requires the <tt>BaseCharacteristic</tt> for both <tt>UnaryTypeTraits</tt> and 
<tt>BinaryTypeTraits</tt> to be a specialization of <tt>integral_constant</tt>, which is inconsistent with the current design of 
<tt>conjunction</tt> and <tt>disjunction</tt>.</p></li>
<li><p>The requirement in 20.15.1 [meta.rqmts] that "member names of the <tt>BaseCharacteristic</tt> shall not be hidden 
and shall be unambiguously available" seems impossible to meet in every case, since the arbitrary base class from which a 
specialization of <tt>conjunction</tt> or <tt>disjunction</tt> derives may contain members called <tt>conjunction</tt> or 
<tt>disjunction</tt> that will necessarily be hidden.</p></li>
</ul>
<p><i>[2016-08 Chicago]</i></p>

<p>Ville provided wording for both <a href="lwg-active.html#2567">2567</a> and <a href="lwg-active.html#2568">2568</a></p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>In [meta.logical]/3, edit as follows:</p>

<p>The <del>BaseCharacteristic of a</del> specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that</ins>
is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
<ins>aforementioned base</ins><del>BaseCharacteristic</del> is
the last type in the list.
[ Note: This means a specialization of conjunction does
not necessarily <del>have a BaseCharacteristic
of</del> <ins>derive from</ins> either true_type or
false_type. — end note ]</p>

<p>In [meta.logical]/6, edit as follows:</p>

<p>The <del>BaseCharacteristic of a</del> specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that</ins>
is the first type <tt>Bi</tt> in the list <tt>false_type, B1, ..., BN</tt> for
which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
<ins>aforementioned base</ins><del>BaseCharacteristic</del> is
the last type in the list.
[ Note: This means a specialization of disjunction does
not necessarily <del>have a BaseCharacteristic
of</del> <ins>derive from</ins> either true_type or
false_type. — end note ]</p>
</blockquote>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>In [meta.logical]/3, edit as follows:</p>

<p>The <del>BaseCharacteristic of a</del> specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either<br/>
* the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value == false</tt>, or<br/>
* if there is no such <tt>Bi</tt>, the last type in the list.</ins><br/>
<del>is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
BaseCharacteristic is the last type in the list.</del><br/>
[ Note: This means a specialization of <tt>conjunction</tt> does
not necessarily <del>have a BaseCharacteristic
of</del> <ins>derive from</ins> either true_type or
false_type. — end note ]</p>

<p>In [meta.logical]/6, edit as follows:</p>
<p>The <del>BaseCharacteristic of a</del> specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either<br/>
* the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value != false</tt>, or<br/>
* if there is no such <tt>Bi</tt>, the last type in the list.</ins><br/>
<del>is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
BaseCharacteristic is the last type in the list.</del><br/>
[ Note: This means a specialization of <tt>disjunction</tt> does
not necessarily <del>have a BaseCharacteristic
of</del> <ins>derive from</ins> either true_type or
false_type. — end note ]</p></blockquote>

Merged the resolution of <a href="lwg-active.html#2587">2587</a> with this issue. This proposed resolution
resolves both, and includes fixes from Daniel for negation.

Last review of this with LWG turned up a true_type typo in the definition of disjunction, and some editorial changes.
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to N4606.</p>
<ol>
<li>
<p>In 20.15.8 [meta.logical] p3, edit as follows:</p>
<pre>
template&lt;class... B&gt; struct conjunction : <em>see below</em> { };
</pre>
<blockquote>
<p>-3- The <del>BaseCharacteristic of a</del> specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either</ins>
<ul>
<li><ins>the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>bool(Bi::value)</tt> is <tt>false</tt>, or</ins></li>
<li><ins>if there is no such <tt>Bi</tt>, the last type in the list.</ins></li>
</ul>
<del>is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
BaseCharacteristic is the last type in the list.</del></p>
<p><ins>-?- The member names of the base class, other than <tt>conjunction</tt> and <tt>operator=</tt>,
shall not be hidden and shall be unambiguously available in <tt>conjunction</tt>. [<em>Note: </em>
This means a specialization of <tt>conjunction</tt> does not necessarily <del>have a BaseCharacteristic
of</del> <ins>inherit from</ins> either <tt>true_type</tt> or <tt>false_type</tt>.
&mdash;<em>end note</em>]</ins></p>
</blockquote>
</li>

<li>
<p>In 20.15.8 [meta.logical] p6, edit as follows:</p>
<pre>
template&lt;class... B&gt; struct disjunction : <em>see below</em> { };
</pre>
<blockquote>
<p>-6- The <del>BaseCharacteristic of a</del> specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either</ins>
<ul>
<li><ins>the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>bool(Bi::value)</tt> is <tt>true</tt>, or,</ins></li>
<li><ins>if there is no such <tt>Bi</tt>, the last type in the list.</ins></li>
</ul>
<del>is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
BaseCharacteristic is the last type in the list.</del></p>
<p><ins>-?- The member names of the base class, other than <tt>disjunction</tt> and <tt>operator=</tt>,
shall not be hidden and shall be unambiguously available in <tt>disjunction</tt>. [<em>Note: </em>This
means a specialization of <tt>disjunction</tt> does not necessarily <del>have a BaseCharacteristic
of</del> <ins>inherit from</ins> either <tt>true_type</tt> or <tt>false_type</tt>.
&mdash;<em>end note</em>]</ins></p>
</blockquote>
</li>

<li>
<p>In 20.15.8 [meta.logical] p8, edit as follows</p>
<pre>
template&lt;class B&gt; struct negation : bool_constant&lt;!<ins>bool(</ins>B::value<ins>)</ins>&gt; { };
</pre>
<blockquote>
<p>
-8- The class template negation forms the logical negation of its template type argument. The type
<tt>negation&lt;B&gt;</tt> is a UnaryTypeTrait with a BaseCharacteristic of
<tt>bool_constant&lt;!<ins>bool(</ins>B::value<ins>)</ins>&gt;</tt>.
</p>
</blockquote>
</li>
</ol>
</blockquote>
<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


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

<ol>
<li>
<p>In 20.15.8 [meta.logical] p3, edit as follows:</p>
<pre>
template&lt;class... B&gt; struct conjunction : <em>see below</em> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>-3- The <del>BaseCharacteristic of a</del> specialization <tt>conjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either</ins>
<ol style="list-style-type:none">
<li>&mdash; <ins>the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>bool(Bi::value)</tt> is <tt>false</tt>, or</ins></li>
<li>&mdash; <ins>if there is no such <tt>Bi</tt>, the last type in the list.</ins></li>
</ol>
<del>is the first type <tt>Bi</tt> in the list <tt>true_type, B1, ..., BN</tt> for
which <tt>Bi::value == false</tt>, or if every <tt>Bi::value != false</tt>, the
BaseCharacteristic is the last type in the list.</del>[<em>Note: </em>
This means a specialization of <tt>conjunction</tt> does not necessarily <del>have a BaseCharacteristic
of</del> <ins>inherit from</ins> either <tt>true_type</tt> or <tt>false_type</tt>.
&mdash;<em>end note</em>]</p>
<p><ins>-?- The member names of the base class, other than <tt>conjunction</tt> and <tt>operator=</tt>,
shall not be hidden and shall be unambiguously available in <tt>conjunction</tt>.</ins></p>
</blockquote>
</li>

<li>
<p>In 20.15.8 [meta.logical] p6, edit as follows:</p>
<pre>
template&lt;class... B&gt; struct disjunction : <em>see below</em> { };
</pre>
<blockquote>
<p>
[&hellip;]
<p/>-6- The <del>BaseCharacteristic of a</del> specialization <tt>disjunction&lt;B1, ..., BN&gt;</tt>
<ins>has a public and unambiguous base that is either</ins>
<ol style="list-style-type:none">
<li>&mdash; <ins>the first type <tt>Bi</tt> in the list <tt>false_type, B1, ..., BN</tt> for
which <tt>bool(Bi::value)</tt> is <tt>true</tt>, or,</ins></li>
<li>&mdash; <ins>if there is no such <tt>Bi</tt>, the last type in the list.</ins></li>
</ol>
<del>is the first type <tt>Bi</tt> in the list <tt>false_type, B1, ..., BN</tt> for
which <tt>Bi::value != false</tt>, or if every <tt>Bi::value == false</tt>, the
BaseCharacteristic is the last type in the list.</del>[<em>Note: </em>This
means a specialization of <tt>disjunction</tt> does not necessarily <del>have a BaseCharacteristic
of</del> <ins>inherit from</ins> either <tt>true_type</tt> or <tt>false_type</tt>.
&mdash;<em>end note</em>]</p>
<p><ins>-?- The member names of the base class, other than <tt>disjunction</tt> and <tt>operator=</tt>,
shall not be hidden and shall be unambiguously available in <tt>disjunction</tt>.</ins></p>
</blockquote>
</li>

<li>
<p>In 20.15.8 [meta.logical] p8, edit as follows</p>
<pre>
template&lt;class B&gt; struct negation : <ins><em>see below</em></ins><del><tt>bool_constant&lt;!B::value&gt;</tt></del> { };
</pre>
<blockquote>
<p>
-8- The class template negation forms the logical negation of its template type argument. The type
<tt>negation&lt;B&gt;</tt> is a UnaryTypeTrait with a BaseCharacteristic of
<tt>bool_constant&lt;!<ins>bool(</ins>B::value<ins>)</ins>&gt;</tt>.
</p>
</blockquote>
</li>
</ol>




<hr>
<h3><a name="2569" href="#2569">2569.</a> <tt>conjunction</tt> and <tt>disjunction</tt> requirements are too strict</h3>
<p><b>Section:</b> 20.15.8 [meta.logical] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-11 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.logical">active issues</a> in [meta.logical].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.logical">issues</a> in [meta.logical].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
20.15.8 [meta.logical]/2 and /5 impose the following requirement on the arguments of <tt>conjunction</tt> and <tt>disjunction</tt>:
</p>
<blockquote><p>
Every template type argument shall be usable as a base class and shall have a static data member value which is convertible to 
<tt>bool</tt>, is not hidden, and is unambiguously available in the type.
</p></blockquote>
<p>
Since the requirement is unconditional, it applies even to type arguments whose instantiation is not required due to short circuiting. 
This seems contrary to the design intent, expressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html">P0013R1</a>, 
that it is valid to write <tt>conjunction_v&lt;is_class&lt;T&gt;, is_foo&lt;T&gt;&gt;</tt> even if instantiating 
<tt>is_foo&lt;T&gt;::value</tt> is ill-formed for non-class types.
</p>
<p><i>[2016-08 Chicago]</i></p>

<p>Ville provided wording for both <a href="lwg-active.html#2569">2569</a> and <a href="lwg-active.html#2570">2570</a>.</p>
<p>Tuesday AM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p><i>[We recommend applying the proposed resolution for LWG issues 2567 and 2568 before this
proposed resolution, lest the poor editor gets confused.]</i></p>


<p>In [meta.logical],</p>

<p>- insert a new paragraph before paragraph 2:</p>

<p><ins>The class template <tt>conjunction</tt> forms the logical conjunction of its
template type arguments.</ins></p>

<p>- move paragraph 4 before paragraph 2, and edit
paragraph 2 as follows:</p>

<p><del>The class template <tt>conjunction</tt> forms the logical conjunction of its
template type arguments.</del>
Every template type argument <ins>for which <tt>Bi::value</tt> is instantiated</ins>
shall be usable as a base class and shall have a member value which is
convertible to <tt>bool</tt>, is not hidden, and is unambiguously available in the type.</p>

<p>- insert a new paragraph before paragraph 5:</p>

<p><ins>The class template <tt>disjunction</tt> forms the logical disjunction
of its template type arguments.</ins></p>

<p>- move paragraph 7 before paragraph 5, and edit
paragraph 5 as follows:</p>

<p><del>The class template <tt>disjunction</tt> forms the logical disjunction
of its template type arguments.</del>
Every template type argument <ins>for which <tt>Bi::value</tt> is instantiated</ins>
shall be usable as a base class and shall have a member value which is
convertible to <tt>bool</tt>, is not hidden, and is unambiguously available in the type.</p>





<hr>
<h3><a name="2570" href="#2570">2570.</a> [fund.ts.v2] <tt>conjunction</tt> and <tt>disjunction</tt> requirements are too strict</h3>
<p><b>Section:</b> 99 [fund.ts.v2::meta.logical] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2015-12-11 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#fund.ts.v2::meta.logical">active issues</a> in [fund.ts.v2::meta.logical].</p>
<p><b>View all other</b> <a href="lwg-index.html#fund.ts.v2::meta.logical">issues</a> in [fund.ts.v2::meta.logical].</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>
99 [meta.logical]/2 and /5 impose the following requirement on the arguments of <tt>conjunction</tt> and <tt>disjunction</tt>:
</p>
<blockquote><p>
Every template type argument shall be usable as a base class and shall have a static data member value which is convertible to 
<tt>bool</tt>, is not hidden, and is unambiguously available in the type.
</p></blockquote>
<p>
Since the requirement is unconditional, it applies even to type arguments whose instantiation is not required due to short circuiting. 
This seems contrary to the design intent, expressed in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/p0013r1.html">P0013R1</a>, 
that it is valid to write <tt>conjunction_v&lt;is_class&lt;T&gt;, is_foo&lt;T&gt;&gt;</tt> even if instantiating 
<tt>is_foo&lt;T&gt;::value</tt> is ill-formed for non-class types.
</p>

<p><i>[2016-06 Oulu]</i></p>

<p>Alisdair has a paper in progress addressing this</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Ville provided wording for both <a href="lwg-active.html#2569">2569</a> and <a href="lwg-active.html#2570">2570</a>.</p>
<p>Tuesday AM: Move to Tentatively Ready</p>


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





<hr>
<h3><a name="2578" href="#2578">2578.</a> Iterator requirements should reference iterator traits</h3>
<p><b>Section:</b> 24.2 [iterator.requirements], 24.4.1 [iterator.traits] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2016-01-05 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#iterator.requirements">active issues</a> in [iterator.requirements].</p>
<p><b>View all other</b> <a href="lwg-index.html#iterator.requirements">issues</a> in [iterator.requirements].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
See <a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=38504">this reflector discussion</a>
for background.
<p/>
24.2 [iterator.requirements] attempts to establish requirements for iterators,
but 24.4.1 [iterator.traits]/1 establishes further requirements that must be met
in order to author a portable iterator that works with existing implementations.
Failing to meet the requirements of the latter will fail to work in practice.
The former requirements should reference the latter, normatively.
</p>

<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
After [iterator.requirements.general]/5, insert the following new paragraph:

<blockquote>
<p>
<ins>
-?- In addition to the requirements in this sub-clause, the nested <em>typedef-name</em>s specified
in ([iterator.traits]) shall be provided for the iterator type. [<i>Note:</i>
Either the iterator type must provide the <em>typedef-name</em>s directly (in which
case iterator_traits pick them up automatically), or an iterator_traits
specialization must provide them. <i>-end note</i>]
</ins>
</p>
</blockquote>





<hr>
<h3><a name="2584" href="#2584">2584.</a> <tt>&lt;regex&gt;</tt> ECMAScript <tt>IdentityEscape</tt> is ambiguous</h3>
<p><b>Section:</b> 28.13 [re.grammar] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy O'Neal III <b>Opened:</b> 2016-01-13 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.grammar">active issues</a> in [re.grammar].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.grammar">issues</a> in [re.grammar].</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>
Stephan and I are seeing differences in implementation for how non-special characters should be handled in the 
<tt>IdentityEscape</tt> part of the ECMAScript grammar. For example:
</p>
<blockquote><pre>
#include &lt;stdio.h&gt;
#include &lt;iostream&gt;
#ifdef USE_BOOST
#include &lt;boost/regex.hpp&gt;
using namespace boost;
#else
#include &lt;regex&gt;
#endif
using namespace std;

int main() {
  try {
    const regex r("\\z");
    cout &lt;&lt; "Constructed \\z." &lt;&lt; endl;
    if (regex_match("z", r))
      cout &lt;&lt; "Matches z" &lt;&lt; endl;
  } catch (const regex_error&amp; e) {
      cout &lt;&lt; e.what() &lt;&lt; endl;
  }
}
</pre></blockquote>
<p>
libstdc++, boost, and browsers I tested with (Microsoft Edge, Google Chrome) all happily interpret <tt>\z</tt>, which 
otherwise has no meaning, as an identity character escape for the letter <tt>z</tt>.
libc++ and msvc++ say that this is invalid, and throw <tt>regex_error</tt> with <tt>error_escape</tt>.
<p/>
ECMAScript 3 (which is what C++ currently points to) seems to agree with libc++ and msvc++:
</p>
<blockquote>
<pre>
IdentityEscape ::
  SourceCharacter <b>but not</b> IdentifierPart

IdentifierPart ::
  IdentifierStart
  UnicodeCombiningMark
  UnicodeDigit
  UnicodeConnectorPunctuation
  \ UnicodeEscapeSequence

IdentifierStart ::
  UnicodeLetter
  $
  _
  \ UnicodeEscapeSequence
</pre>
</blockquote>
<p>
But this doesn't make any sense &mdash; it prohibits things like <tt>\$</tt> which users absolutely need to be able to escape. 
So let's look at ECMAScript 6. I believe this says much the same thing, but updates the spec to better handle Unicode by 
referencing what the Unicode standard says is an identifier character:
</p>
<blockquote>
<pre>
IdentityEscape ::
  SyntaxCharacter
  /
  SourceCharacter <b>but not</b> UnicodeIDContinue
  
UnicodeIDContinue ::
  any Unicode code point with the Unicode property "ID_Continue", "Other_ID_Continue", or "Other_ID_Start"
</pre>
</blockquote>
<p>
However, ECMAScript 6 has an appendix B defining "additional features for web browsers" which says:
</p>
<blockquote>
<pre>
IdentityEscape ::
  SourceCharacter <b>but not</b> c
</pre>
</blockquote>
<p>
which appears to agree with what libstdc++, boost, and browsers are doing.
<p/>
What should be the correct behavior here?
</p>

<p><i>[2016-08, Chicago]</i></p>

<p>Monday PM: Move to tentatively ready</p>


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

<ol>
<li><p>Change 28.13 [re.grammar]/3 as indicated:</p>

<blockquote>
<p>
-3- The following productions within the ECMAScript grammar are modified as follows:
</p>
<blockquote><pre>
ClassAtom ::
  -
  ClassAtomNoDash
  ClassAtomExClass
  ClassAtomCollatingElement
  ClassAtomEquivalence
  
<ins>IdentityEscape ::
  SourceCharacter <b>but not</b> c</ins>
</pre></blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2589" href="#2589">2589.</a> <tt>match_results</tt> can't satisfy the requirements of a container</h3>
<p><b>Section:</b> 28.10 [re.results] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> S. B. Tam <b>Opened:</b> 2016-01-24 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#re.results">active issues</a> in [re.results].</p>
<p><b>View all other</b> <a href="lwg-index.html#re.results">issues</a> in [re.results].</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>
N4567 28.10 [re.results] p2 mentions
</p>
<blockquote>
<p>
The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specifed in 23.2.3, except that only operations defined for const-qualified sequence
containers are supported.
</p>
</blockquote>
<p>
However, this is impossible because <tt>match_results</tt> has a <tt>operator==</tt> whose semantics differs from the one 
required in Table 95 &mdash; "Container requirements".
<p/>
Table 95 requires that <tt>a == b</tt> is an equivalence relation and means <tt>equal(a.begin(), a.end(), b.begin(), b.end())</tt>. 
But for <tt>match_results</tt>, <tt>a == b</tt> and <tt>equal(a.begin(), a.end(), b.begin(), b.end())</tt> can give different 
results. For example:
</p>
<blockquote><pre>
#include &lt;iostream&gt;
#include &lt;regex&gt;
#include &lt;string&gt;
#include &lt;algorithm&gt;

int main()
{
  std::regex re("a*");
  std::string target("baaab");
  std::smatch a;

  std::regex_search(target, a, re);

  std::string target2("raaau");
  std::smatch b;

  std::regex_search(target2, b, re);

  std::cout &lt;&lt; std::boolalpha;
  std::cout &lt;&lt; (a == b) &lt;&lt; '\n'; // false
  std::cout &lt;&lt; std::equal(a.begin(), a.end(), b.begin(), b.end()) &lt;&lt; '\n'; // true
}
</pre></blockquote>
<p><i>[2016-02, Issues Telecon]</i></p>

Marshall: The submitter is absolutely right, but the proposed resolution is insufficient. We should avoid "shall", for once.<br/>
Jonathan: This is NAD, because the container comparison functions say "unless otherwise stated", 23.3.1p14 and table 97.<br/>
Ville: wrong, table 95 is relevant for ==.<br/>
Jonathan: good point<br/>

<p>2016-05: Marshall cleans up the wording around the change</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 28.10 [re.results] p2 as indicated:</p>
<blockquote><p>
-2- The class template <tt>match_results</tt> shall satisfy the requirements of an allocator-aware container and of a
sequence container, as specified in 23.2.3, except that only operations defined for const-qualified sequence
containers are supported <ins>and that the semantics of comparison functions are different from those required for a 
container</ins>.
</p></blockquote>
</li>
</ol>
</blockquote>

<p>
This wording is relative to N4567.
</p>

<ol>
<li><p>Change 28.10 [re.results] p2 as indicated:</p>
<blockquote><p>
-2- The class template <tt>match_results</tt> <del>shall satisfy</del><ins>satisfies</ins> the requirements of an allocator-aware container and of a
sequence container, <del>as specified in </del><ins>(</ins>23.2.3<ins>)</ins>, except that only operations defined for const-qualified sequence
containers are supported <ins>and the semantics of comparison functions are different from those required for a 
container</ins>.
</p></blockquote>
</li>
</ol>





<hr>
<h3><a name="2591" href="#2591">2591.</a> <tt>std::function</tt>'s member template <tt>target()</tt> should not lead to undefined behaviour</h3>
<p><b>Section:</b> 20.14.12.2.5 [func.wrap.func.targ] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2016-01-31 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#func.wrap.func.targ">issues</a> in [func.wrap.func.targ].</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>
This issue is a spin-off of LWG <a href="lwg-defects.html#2393">2393</a>, it solely focuses on the pre-condition of 20.14.12.2.5 [func.wrap.func.targ] p2:
</p>
<blockquote class="note"><p>
<i>Requires</i>: <tt>T</tt> shall be a type that is Callable (20.9.12.2) for parameter types <tt>ArgTypes</tt> and return type
<tt>R</tt>.
</p></blockquote>
<p>
Originally, the author of this issue here had assumed that simply removing the precondition as a side-step of fixing LWG
<a href="lwg-defects.html#2393">2393</a> would be uncontroversial. Discussions on the 
<a href="http://accu.org/cgi-bin/wg21/message?wg=lib&amp;msg=38356">library reflector</a> indicated that this is not the case, 
although it seemed that there was agreement on removing the undefined behaviour edge-case.
<p/>
There exist basically the following positions:
</p>
<ol>
<li><p>The constraint should be removed completely, the function is considered as having a 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3279.pdf">wide contract</a>.</p>
</li>
<li><p>The pre-condition should be replaced by a <i>Remarks</i> element, that has the effect of making the code ill-formed,
if <tt>T</tt> is a type that is not Lvalue-Callable (20.9.11.2) for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>.
Technically this approach is still conforming with a wide contract function, because the definition of this contract form
depends on runtime constraints.</p></li>
</ol>
<p>
Not yet explicitly discussed, but a possible variant of bullet (2) could be:
</p>
<ol start="3">
<li><p>The pre-condition should be replaced by a <i>Remarks</i> element, that has the effect of SFINAE-constraining
this member: "This function shall not participate in overload resolution unless  <tt>T</tt> is a type that is 
Lvalue-Callable (20.9.11.2) for parameter types <tt>ArgTypes</tt> and return type <tt>R</tt>".
</p></li>
</ol>
<p>
The following describes a list of some selected arguments that have been provided for one or the other position
using corresponding list items. Unless explicitly denoted, no difference has been accounted for option (3) over 
option (2).
</p>
<ol>
<li>
<ol style="list-style-type:lower-alpha">
<li>
<p>It reflects existing implementation practice, Visual Studio 2015 SR1, gcc 6 libstdc++, and clang 3.8.0 libc++ do accept 
the following code:</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;void(*)()&gt;() &lt;&lt; std::endl;
  boost::function&lt;void(int)&gt; f2(foo);
  std::cout &lt;&lt; f2.target&lt;void(*)()&gt;() &lt;&lt; std::endl;
}
</pre></blockquote>
<p>
and consistently output the implementation-specific result for <b>two null pointer</b> values.
</p>
</li>
<li>
<p>
The current
<a href="http://www.boost.org/doc/libs/1_60_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 for the corresponding standard component.
</p>
</li>
<li>
<p>
There is a consistency argument in regard to the free function template <tt>get_deleter</tt>
</p>
<blockquote><pre>
template&lt;class D, class T&gt; 
D* get_deleter(const shared_ptr&lt;T&gt;&amp; p) noexcept;
</pre></blockquote>
<p>
This function also does not impose any pre-conditions on its template argument <tt>D</tt>.
</p>
</li>
</ol>
</li>
<li>
<ol style="list-style-type:lower-alpha">
<li>
<p>
Programmers have control over the type they're passing to <tt>target&lt;T&gt;()</tt>. Passing a non-callable type 
can't possibly retrieve a non-null target, so it seems highly likely to be programmer error. Diagnosing that at 
compile time seems highly preferable to allowing this to return null, always, at runtime.
</p>
</li>
<li>
<p>
If <tt>T</tt> is a reference type then the return type <tt>T*</tt> is ill-formed anyway. This implies that one can't 
blindly call <tt>target&lt;T&gt;</tt> without knowing what <tt>T</tt> is.
</p>
</li>
<li>
<p>
It has been pointed out that some real world code, boiling down to
</p>
<blockquote><pre>
void foo() {}

int main() {
  std::function&lt;void()&gt; f = foo;
  if (f.target&lt;decltype(foo)&gt;()) {
    <i>// fast path</i>
  } else {
    <i>// slow path</i>
  }
}
</pre></blockquote>
<p>
had manifested as a performance issue and preparing a patch that made the library <tt>static_assert</tt> in that
case solved this problem (Note that <tt>decltype(foo)</tt> evaluates to <tt>void()</tt>, but a proper argument of
<tt>target()</tt> would have been the function <em>pointer</em> type <tt>void(*)()</tt>, because a function type 
<tt>void()</tt> is not any <i>Callable</i> type).
</p>
</li>
</ol>
</li>
</ol>
<p>
It might be worth adding that if use case (2 c) is indeed an often occurring idiom, it would make sense to consider
to provide an explicit conversion to a function pointer (w/o template parameters that could be provided incorrectly), 
if the <tt>std::function</tt> object at runtime conditions contains a pointer to a real function, e.g.
</p>
<blockquote><pre>
R(*)(ArgTypes...) target_func_ptr() const noexcept;
</pre></blockquote>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 20.14.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>
<del>-2- <i>Requires</i>: <tt>T</tt> shall be a type that is <tt>Callable</tt> (20.14.12.2 [func.wrap.func]) 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>





<hr>
<h3><a name="2598" href="#2598">2598.</a> <tt>addressof</tt> works on temporaries</h3>
<p><b>Section:</b> 20.10.10.1 [specialized.addressof] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Brent Friedman <b>Opened:</b> 2016-03-06 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#specialized.addressof">issues</a> in [specialized.addressof].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG issue <a href="lwg-defects.html#970">970</a> removed the rvalue reference overload for <tt>addressof</tt>. This allows const prvalues to 
bind to a call to <tt>addressof</tt>, which is dissimilar from the behavior of <tt>operator&amp;</tt>.
</p>
<blockquote><pre>
const vector&lt;int&gt; a();

void b()
{
  auto x = addressof(a()); // "ok"
  auto y = addressof&lt;const int&gt;(0); // "ok"
  auto z = &amp;a(); //error: cannot take address of a temporary
}
</pre></blockquote>

<p><i>[2016-08 Chicago]</i></p>

<p>Tues PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 20.10.2 [memory.syn], header <tt>&lt;memory&gt;</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
[&hellip;]
<i>// 20.9.12, specialized algorithms:</i>
template &lt;class T&gt; constexpr T* addressof(T&amp; r) noexcept;
<ins>template &lt;class T&gt; const T* addressof(const T&amp;&amp; elem) = delete;</ins>
[&hellip;]
</pre>
</blockquote>
</li>

<li><p>Change 20.10.10.1 [specialized.addressof] p1 as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; constexpr T* addressof(T&amp; r) noexcept;
<ins>template &lt;class T&gt; const T* addressof(const T&amp;&amp; elem) = delete;</ins>
</pre>
<blockquote>
<p>
-1- <i>Returns</i>: The actual address of the object or function referenced by <tt>r</tt>, even in the presence of an
overloaded <tt>operator&amp;</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2664" href="#2664">2664.</a> <code>operator/</code> (and other append) semantics not useful if argument has root</h3>
<p><b>Section:</b> 27.10.8.4.3 [path.append], 27.10.8.6 [path.non-member] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Peter Dimov <b>Opened:</b> 2014-05-30 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#path.append">active issues</a> in [path.append].</p>
<p><b>View all other</b> <a href="lwg-index.html#path.append">issues</a> in [path.append].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
  In a recent discussion on the Boost developers mailing list, the semantics of <code>operator /</code>
  and other append operations were questioned:
<p/>
In brief, currently <code>p1 / p2</code> is required to concatenate the
  lexical representation of <code>p1</code> and <code>p2</code>, inserting a
  preferred separator as needed.
<p/>
This means that, for example, <code>&quot;c:\x&quot; / &quot;d:\y&quot;</code> gives <code>
    &quot;c:\x\d:\y&quot;</code>, and that <code>&quot;c:\x&quot; / &quot;\\server\share&quot;</code>
    gives <code>&quot;c:\x\\server\share&quot;</code>. This is rarely, if ever, useful.
<p/>
An alternative interpretation of <code>p1 / p2</code> could be that it yields a
  path that is the approximation of what <code>p2</code> would mean if interpreted
  in an environment in which <code>p1</code> is the starting directory. 
  Under this interpretation, <code>&quot;c:\x&quot; / &quot;d:\y&quot;</code> gives <code>&quot;d:\y&quot;</code>,
  which is more likely to match what was intended.
<p/>
I am not saying that this second interpretation is the right one, but I do say
  that we have reasons to suspect that the first one (lexical concatenation using
  a separator) may not be entirely correct.
  This leads me to think that the behavior of <code>p1 / p2</code>, when <code>p2</code>
  has a root, needs to be left implementation-defined, so that implementations are
  not required to do the wrong thing, as above.
<p/>
This change will not affect the ordinary use case in which <code>p2</code> is a
  relative, root-less, path.
</p>  
<p><i>[17 Jun 2014 Rapperswil LWG will investigate issue at a subsequent meeting.]</i></p>


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

<p>Beman to provide wording.</p>

<p><i>[2016-06-13, Beman provides wording and rationale]</i></p>

<p>
<b>Rationale:</b> The purpose of the append operations is to provide a simple concatenation facility for users 
wishing to extend a path by appending one or more additional elements, and to do so without worrying about the 
details of when a separator is needed. In that context it makes no sense to provide an argument that has a 
<i>root-name</i>. The simplest solution is simply to require <code>!p.has_root_name()</code>.
The other suggested solutions IMO twist the functions into something harder to reason about
yet any advantages for users are purely speculative. The concatenation functions can
be used instead for corner cases.
</p>

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

<p><i>[2016-07-03, Daniel comments]</i></p>

<p>
The same wording area is touched by LWG <a href="lwg-active.html#2732">2732</a>.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to N4594.</p>
<ol>
<li><p><i>Change 27.10.8.4.3 [path.append] path appends as indicated:</i></p>

<blockquote>
<code>path&amp; operator/=(const path&amp; p);</code>
<blockquote>
  <p><ins>-?- <i>Requires:</i> <code>!p.has_root_name()</code>.</ins></p>
  <p>-2- <i>Effects:</i> Appends <code>path::preferred_separator</code> to <tt>pathname</tt> unless:</p>
  <ul>
  <li><p>an added <i>directory-separator</i> would be redundant, or</p></li>
  <li><p>an added <i>directory-separator</i> would change a relative path to an absolute path 
  [<i>Note:</i> An empty path is relative. &mdash; <i>end note</i>], or</p></li>
  <li><p><code>p.empty()</code> is <tt>true</tt>, or</p></li>
  <li><p><code>*p.native().cbegin()</code> is a <i>directory-separator</i>.</p></li>
  </ul>
  <p>Then appends <code>p.native()</code> to <tt>pathname</tt>.</p>
  <p>-3- <i>Returns:</i> <code>*this</code>.</p>
</blockquote>
<code>template &lt;class Source&gt;<br/>
&nbsp; path&amp; operator/=(const Source&amp; source);<br/>
template &lt;class Source&gt;<br/>
&nbsp; path&amp; append(const Source&amp; source);<br/>
template &lt;class InputIterator&gt;<br/>
&nbsp; path&amp; append(InputIterator first, InputIterator last);</code>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> <code>!source.has_root_name()</code> or
<code>!*first.has_root_name()</code>, respectively.</ins>
<p/>
-4- <i>Effects:</i> Appends <code>path::preferred_separator</code> to <tt>pathname</tt>,
converting format and encoding if required (27.10.8.2 [path.cvt]), unless:
</p>
<ul>
  <li><p>an added <i>directory-separator</i> would be redundant, or</p></li>
  <li><p>an added <i>directory-separator</i> would change a relative path to an absolute path, or</p></li>
  <li><p><code>source.empty()</code> is <tt>true</tt>, or</p></li>
  <li><p><code>*source.native().cbegin()</code> is a <i>directory-separator</i>.</p></li>
</ul>
<p>
Then appends the effective range of <code>source</code> (27.10.8.3 [path.req]) or the range
<code>[first, last)</code> to <code>pathname</code>, converting format and encoding if required (27.10.8.2 [path.cvt]).
<p/>
-5- <i>Returns:</i> <code>*this</code>.
</p>
</blockquote>
</blockquote>
</li>

<li><p><i>Change 27.10.8.6 [path.non-member] path non-member functions as indicated:</i></p>

<blockquote>
<code>path operator/(const path&amp; lhs, const path&amp; rhs);</code>
  <blockquote>
  <p><ins>-?- <i>Requires:</i> <code>!rhs.has_root_name()</code>.</ins></p>
  <p>-13- <i>Returns:</i> <code>path(lhs) /= rhs</code>.</p>
  </blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-03 Chicago]</i></p>

<p>After discussion on <a href="lwg-active.html#2732">2732</a>, it was determined that the PR for that issue should be
applied to this issue before it is accepted. That PR changes all the path appends to go through
operator/=, so only one requires element remains necessary.</p>
<p>Fri AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4606, and assumes that the PR for <a href="lwg-active.html#2732">2732</a> is applied.</p>
<ol>
<li>Change 27.10.8.4.3 [path.append] as indicated:
<pre>path&amp; operator/=(const path&amp; p);</pre>
<blockquote>
  <p><ins>-?- <i>Requires:</i> <code>!p.has_root_name()</code>.</ins></p>
  <p>-2- <i>Effects:</i> Appends <code>path::preferred_separator</code> to <tt>pathname</tt> unless:</p>
  <ul style="list-style-type: none">
  <li>&mdash; an added <i>directory-separator</i> would be redundant, or</li>
  <li>&mdash; an added <i>directory-separator</i> would change a relative path to an absolute path
  [<i>Note:</i> An empty path is relative. &mdash; <i>end note</i>], or</li>
  <li>&mdash; <code>p.empty()</code> is <tt>true</tt>, or</li>
  <li>&mdash; <code>*p.native().cbegin()</code> is a <i>directory-separator</i>.</li>
  </ul>
  <p>Then appends <code>p.native()</code> to <tt>pathname</tt>.</p>
  <p>-3- <i>Returns:</i> <code>*this</code>.</p>
</blockquote>
</li>
<li>Change 27.10.8.6 [path.non-member] p13 as indicated:
<pre>path operator/(const path&amp; lhs, const path&amp; rhs);</pre>
<blockquote>
<p>-13- <em><del>Returns</del><ins>Effects</ins>:</em> <ins>Equivalent to </ins><code>
<ins>return </ins>path(lhs) /= rhs;</code>.</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2672" href="#2672">2672.</a> Should is_empty use error_code in its specification?</h3>
<p><b>Section:</b> 27.10.15.19 [fs.op.is_empty] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-08-01 <b>Last modified:</b> 2016-08-03</p>
<p><b>Priority: </b>3
</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 descriptions of most functions are explicit about the use of the <code>ec</code> argument,
  either saying something like "<code>foo(p)</code> or <code>foo(p, ec)</code>, respectively" or using the
  <code>ec</code> argument like <code>foo(p[, ec])</code>, but <code>is_empty</code> does not.
</p>
<p>
27.10.15.19 [fs.op.is_empty]/2 refers to <code>ec</code> unconditionally, but more importantly
  27.10.15.19 [fs.op.is_empty]/3 doesn't pass <code>ec</code> to the <code>directory_iterator</code>
  constructor or the <code>file_size</code> function.
</p>

  <p><i>[
    9 Oct 2014 Beman supplies proposed wording.
  ]</i></p>


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

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li>
  <blockquote>
  <pre>
    bool is_empty(const path&amp; p);
    bool is_empty(const path&amp; p, error_code&amp; ec) noexcept;
  </pre>
  <blockquote>
    <p>
      <i>Effects:</i>
    </p>
    <ul>
      <li>
        Determine <code>file_status s</code>, as if by
        <ins>
          <code>status(p)</code> or
        </ins> <code>status(p, ec)</code><ins>, respectively</ins>.
      </li>
      <li>
        <ins>
          For the signature with argument <code>ec</code>, return <code>false</code> if
          an error occurred.
        </ins>
      </li>
      <li>
        <ins>
          Otherwise, if <code>is_directory(s)</code>:
        </ins>
        <ul>
          <li>
            <ins>
              Create <code>directory_iterator itr</code>, as if by
              <code>directory_iterator(p)</code>
              or <code>directory_iterator(p, ec)</code>, respectively.
            </ins>
          </li>
          <li>
            <ins>
              For the signature with argument <code>ec</code>, return <code>false</code> if
              an error occurred.
            </ins>
          </li>
          <li>
            <ins>
              Otherwise, return <code>itr == directory_iterator()</code>.
            </ins>
          </li>
        </ul>
      </li>
      <li>
        <ins>Otherwise:</ins>
        <ul>
          <li>
            <ins>
              Determine <code>uintmax_t sz</code>, as if by <code>
                file_size(p)
              </code> or<code> file_size(p, ec)</code>, respectively
            </ins>.
          </li>
          <li>
            <ins>
              For the signature with argument <code>ec</code>, return <code>false</code> if
              an error occurred.
            </ins>
          </li>
          <li>
            <ins>
              Otherwise, return <code>sz == 0</code>.
            </ins>
          </li>
        </ul>
      </li>
    </ul>
    <p>
      <ins>
        <i>Remarks:</i> The temporary objects described in <i>Effects</i>
        are for exposition only. Implementations are not required to create them.
      </ins>
    </p>
    <p>
      <i>Returns:</i>
      <del>
        <code>
          is_directory(s) ? directory_iterator(p) == directory_iterator()
          : file_size(p) == 0;
        </code>
      </del>
      <ins>
        See <i>Effects</i>.
      </ins>
    </p>
    <blockquote>
      <p>
        <del>
          The signature with argument <code>ec</code> returns <code>false</code> if
          an error occurs.
        </del>
      </p>
    </blockquote>
    <p>
      <i>Throws:</i> As specified in Error reporting (7).
    </p>
  </blockquote>
  </blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed PM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
  <blockquote>
  <pre>
    bool is_empty(const path&amp; p);
    bool is_empty(const path&amp; p, error_code&amp; ec) noexcept;
  </pre>
  <blockquote>
    <p>
      <i>Effects:</i>
    </p>
    <ul>
      <li>
        Determine <code>file_status s</code>, as if by
        <ins>
          <code>status(p)</code> or
        </ins> <code>status(p, ec)</code><ins>, respectively</ins>.
      </li>
      <li>
        <ins>
          For the signature with argument <code>ec</code>, return <code>false</code> if
          an error occurred.
        </ins>
      </li>
      <li>
        <ins>
          Otherwise, if <code>is_directory(s)</code>:
        </ins>
        <ul>
          <li>
            <ins>
              Create <code>directory_iterator itr</code>, as if by
              <code>directory_iterator(p)</code>
              or <code>directory_iterator(p, ec)</code>, respectively.
            </ins>
          </li>
          <li>
            <ins>
              For the signature with argument <code>ec</code>, return <code>false</code> if
              an error occurred.
            </ins>
          </li>
          <li>
            <ins>
              Otherwise, return <code>itr == directory_iterator()</code>.
            </ins>
          </li>
        </ul>
      </li>
      <li>
        <ins>Otherwise:</ins>
        <ul>
          <li>
            <ins>
              Determine <code>uintmax_t sz</code>, as if by <code>
                file_size(p)
              </code> or<code> file_size(p, ec)</code>, respectively
            </ins>.
          </li>
          <li>
            <ins>
              For the signature with argument <code>ec</code>, return <code>false</code> if
              an error occurred.
            </ins>
          </li>
          <li>
            <ins>
              Otherwise, return <code>sz == 0</code>.
            </ins>
          </li>
        </ul>
      </li>
    </ul>
    <p>
      <del>
      <i>Returns:</i>
        <code>
          is_directory(s) ? directory_iterator(p) == directory_iterator()
          : file_size(p) == 0;
        </code>
      </del>
    </p>
    <blockquote>
      <p>
        <del>
          The signature with argument <code>ec</code> returns <code>false</code> if
          an error occurs.
        </del>
      </p>
    </blockquote>
    <p>
      <i>Throws:</i> As specified in Error reporting (7).
    </p>
  </blockquote>
  </blockquote>
</li>
</ol>





<hr>
<h3><a name="2678" href="#2678">2678.</a> <tt>std::filesystem</tt> enum classes overspecified</h3>
<p><b>Section:</b> 27.10.10.1 [enum.file_type], 27.10.10.2 [enum.copy_options], 27.10.10.4 [enum.directory_options] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-03-19 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</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 enum class <tt>std::filesystem::file_type</tt> specifies a collection of enumerators for describing the type of 
a file, but also specifies (1) the numeric values of the enumerators, and (2) that an implementation cannot extend the 
list with additional types known to it (and by extension, the standard cannot extend the list in future versions without 
breakage).
</p>
<p>
These both seem like mistakes in the design. I would suggest we remove the 
specification of numerical values, and maybe also
</p>
<ul>
  <li><p>we allow implementations to add new implementation-defined value</p></li>
  <li><p>we replace <tt>std::filesystem::file_type::unknown</tt> with a value that <em>only</em> 
  means &quot;exists but type could not be determined&quot; and use 
  implementation-specific values for other possibilities.</p></li>
</ul>
 <p>
 Similar overspecification exists for <tt>std::filesystem::copy_options</tt> and 
 <tt>std::filesystem::directory_options</tt>, where again precise numerical values are specified.
 </p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>
Strike the "Value" column from:
</p>
<ul>
  <li><p>27.10.10.1 [enum.file_type], Table 145 Enum class <code>file_type</code> </p></li>
  <li><p>27.10.10.2 [enum.copy_options], Table 146 Enum class <code>copy_options</code> </p></li>
  <li><p>27.10.10.4 [enum.directory_options], Table 148 Enum class <code>enum.directory_options</code>.</p></li>
</ul>
</li>

<li><p>Change 27.10.10.1 [enum.file_type] Table 145 Enum class <code>file_type</code> as indicated:</p>

<blockquote>
 <table border="1" cellpadding="5" cellspacing="0" style="border-collapse: collapse">
    <tr>
      <td><b>Constant</b></td>
      <td><b>Meaning</b></td>
    </tr>
    <tr>
      <td><code>none</code></td>
      <td>The type of the file has not been determined or an error occurred 
      while trying to determine the type.</td>
    </tr>
    <tr>
      <td><code>not_found</code></td>
      <td>Pseudo-type indicating the file was not found. [ <i>Note:</i>
      The file not being
      found is not considered an error while determining the type of a file. 
      <i>—end note</i> ]</td>
    </tr>
    <tr>
      <td><code>regular</code></td>
      <td>Regular file</td>
    </tr>
    <tr>
      <td><code>directory</code></td>
      <td>Directory file</td>
    </tr>
    <tr>
      <td><code>symlink</code></td>
      <td>Symbolic link file</td>
    </tr>
    <tr>
      <td><code>block</code></td>
      <td>Block special file</td>
    </tr>
    <tr>
      <td><code>character</code></td>
      <td>Character special file</td>
    </tr>
    <tr>
      <td><code>fifo</code></td>
      <td>FIFO or pipe file</td>
    </tr>
    <tr>
      <td><code>socket</code></td>
      <td>Socket file</td>
    </tr>
    <tr>
      <td><ins>implementation-<br/>defined</ins></td>
      <td><ins>Implementations that support file systems having file types
      in addition to the above file_type types shall supply
      implementation-defined <code>file_type</code> 
      constants to separately identify each of those additional
      file types</ins></td>
    </tr>
    <tr>
      <td><code>unknown</code></td>
      <td><del>The file does exist, but is of an operating system dependent type not 
      covered by any of the other cases or the process does not have permission to query
      the file type</del> <ins>The file exists but the type could not be determined</ins></td>
    </tr>
  </table>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2679" href="#2679">2679.</a> Inconsistent Use of Effects and Equivalent To</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> Dawn Perchik <b>Opened:</b> 2016-04-14 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</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>
<ul>
<li><p>
Some <i>Effects</i>: were intended to include the "Equivalent to" phrasing where no or different words were used.  
See examples in <tt>std::filesystem</tt> and throughout the library.
</p></li>
<li><p>
The wording in [structure.specifications]/4 is incorrect and <i>Effects</i>: throughout the library which use 
(or were intended to use) the "Equivalent to" phrasing need to be checked to make sure they fit the intended wording.
</p></li>
</ul>

<p><i>[2016-04, Issues Telecon]</i></p>

<p>
The PR is fine; but bullet #1 in the report really should have a list of places to change.
<p/>
Jonathan checked throughout the library for bullet #2 and found two problems in [string.access], 
which have been added to the PR.
</p>

<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri PM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<ol>
<li>
<p>Change [structure.specifications]/4 as indicated:</p>

<blockquote>
<p>
"[&hellip;] if <tt>F</tt> has no <i>Returns</i>: element, a non-<tt>void</tt> return from <tt>F</tt> is specified by the 
<del>Returns: elements</del><ins>return statements</ins> in the code sequence."
</p>
</blockquote>
</li>

<li><p>Add two <tt>return</tt> keywords to [string.access]:</p>

<blockquote>
<pre>
const charT&amp; front() const;
charT&amp; front();
</pre>
<blockquote>
<p>-7- <i>Requires:</i> <code>!empty()</code>.</p>
<p>-8- <i>Effects:</i> Equivalent to <code><ins>return </ins>operator[](0)</code>.</p>
</blockquote>

<pre>
const charT&amp; back() const;
charT&amp; back();
</pre>
<blockquote>
<p>-9- <i>Requires:</i> <code>!empty()</code>.</p>
<p>-10- <i>Effects:</i> Equivalent to <code><ins>return </ins>operator[](size() - 1)</code>.</p>
</blockquote>
</blockquote>
</li>
</ol>







<hr>
<h3><a name="2680" href="#2680">2680.</a> Add "Equivalent to" to filesystem</h3>
<p><b>Section:</b> 27.10 [filesystems] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Beman Dawes <b>Opened:</b> 2016-04-15 <b>Last modified:</b> 2016-08-08</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>The IS project editors have requested that filesystem <i>Effects</i> elements specified purely as C++ code 
include the phrase "Equivalent to" if this is the intent. They do not consider this change to be editorial.</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>


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

<p><i><section>27.10.8.4.5 [path.modifiers]</section></i></p>
<blockquote>
<pre>path&amp; replace_filename(const path&amp; replacement);</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins></p>
<pre>remove_filename();
operator/=(replacement);</pre>
</blockquote>
</blockquote>

<p><i><section>27.10.8.6 [path.non-member]</section></i></p>
<blockquote>
<pre>void swap(path&amp; lhs, path&amp; rhs) noexcept;</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins> <code>lhs.swap(rhs)</code></p>
</blockquote>
</blockquote>

<p><i><section>27.10.8.6.1 [path.io]</section></i></p>
<blockquote>
<pre>template &lt;class charT, class traits&gt;
basic_ostream&lt;charT, traits&gt;&amp;
operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os, const path&amp; p);</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins> <code>os &lt;&lt; quoted(p.string&lt;charT, traits&gt;())</code>.</p>
<pre></pre>
</blockquote>
</blockquote>

<p><i><section>27.10.8.6.1 [path.io]</section></i></p>
<blockquote>
<pre>template &lt;class charT, class traits&gt;
basic_istream&lt;charT, traits&gt;&amp;
operator&gt;&gt;(basic_istream&lt;charT, traits&gt;&amp; is, path&amp; p);</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins></p>
<pre>basic_string&lt;charT, traits&gt; tmp;
is &gt;&gt; quoted(tmp);
p = tmp;</pre>
</blockquote>
</blockquote>

<p><i><section>27.10.15.3 [fs.op.copy]</section></i></p>
<blockquote>
<pre>void copy(const path&amp; from, const path&amp; to);
void copy(const path&amp; from, const path&amp; to, error_code&amp; ec) noexcept;</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins> <code>copy(from, to, copy_options::none)</code> or <code>copy(from, to, 
copy_options::none, ec)</code>, respectively.</p>
</blockquote>
</blockquote>

<p><i><section>27.10.15.5 [fs.op.copy_symlink]</section></i></p>
<blockquote>
<pre>void copy_symlink(const path&amp; existing_symlink, const path&amp; new_symlink);
void copy_symlink(const path&amp; existing_symlink, const path&amp; new_symlink,
  error_code&amp; ec) noexcept;</pre>
<blockquote>
<p><i>Effects:</i> <ins>Equivalent to:</ins> <code><i>function</i>(read_symlink(existing_symlink), new_symlink)</code> or
<code><i>function</i>(read_symlink(existing_symlink, ec), new_symlink, ec)</code>, respectively, 
where <code><i>function</i></code>
is <code>create_symlink</code> or <code>create_directory_symlink</code>, as appropriate.</p>
</blockquote>
</blockquote>







<hr>
<h3><a name="2681" href="#2681">2681.</a> <code>filesystem::copy()</code> cannot copy symlinks</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-08-08</p>
<p><b>Priority: </b>2
</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>27.10.15.3 [fs.op.copy] paragraph 3 bullet (3.4) says that if <code>is_symlink(f)</code> and
<code>copy_options</code> is set in options then it should copy a symlink, but that
case cannot be reached.</p>

<p><code>is_symlink(f)</code> can only be true if f was set using
<code>symlink_status(from)</code>, but that doesn't happen unless one of
<code>create_symlinks</code> or <code>skip_symlinks</code> is set in options. It should depend
on <code>copy_symlinks</code> too.</p>

<p>I'm not sure what the correct behaviour is, but I don't think we
want to simply add a check for <code>copy_symlinks</code> in bullet (3.1) because
that would mean that <code>t = symlink_status(to)</code>, and I don't think we want
that. Consider <code>'touch file; mkdir dir; ln -s dir link;'</code> and then
<code>filesystem::copy("file", "link",
filesystem::copy_options::copy_symlinks)</code>. If <code>t = symlink_status(to)</code>
then <code>is_directory(t) == false</code>, and we don't use bullet (3.5.4) but go
to (3.5.5) instead and fail. So when <code>copy_symlinks</code> is set we still
need to use <code>t = status(to)</code> as specified today.</p>

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

<p>
This is related to <a href="lwg-active.html#2682">2682</a>; and should be considered together.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>Modify paragraph 3 of 27.10.15.3 [fs.op.copy] as shown:</p>

<blockquote>
<p><i>Effects:</i> Before the first use of <code>f</code> and <code>t</code>:<br/><br/>
 — If <code>(options &amp; copy_options::create_symlinks) != copy_options::none ||
(options &amp; copy_options::skip_symlinks) != copy_options::none</code>
then <code>auto f = symlink_status(from)</code> and if needed <code>auto t = symlink_status(to)</code>.<br/><br/>
<ins>
 — Otherwise, if <code>(options &amp; copy_options::copy_symlinks) != copy_options::none</code>
then <code>auto f = symlink_status(from)</code> and if needed <code>auto t = status(to)</code>.
</ins><br/>
 — Otherwise, <code>auto f = status(from)</code> and if needed <code>auto t = status(to)</code>.
</p>
</blockquote>





<hr>
<h3><a name="2686" href="#2686">2686.</a> Why is <tt>std::hash</tt> specialized for <tt>error_code</tt>, but not <tt>error_condition</tt>?</h3>
<p><b>Section:</b> 19.5.1 [system_error.syn] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-05-03 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>3
</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>
Both <tt>error_code</tt> and <tt>error_condition</tt> have an <tt>operator&lt;</tt> overload, 
enabling their use in associative containers without having to write a custom comparator. 
</p>
<p>
However, only <tt>error_code</tt> has a <tt>std::hash</tt>
specialization. So it's possible to have a
<tt>set&lt;error_code&gt;</tt>, a <tt>set&lt;error_condition&gt;</tt>,
an <tt>unordered_set&lt;error_code&gt;</tt>, but not an
<tt>unordered_set&lt;error_condition&gt;</tt>. This seems...odd.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Edit 19.5.1 [system_error.syn], header <tt>&lt;system_error&gt;</tt> synopsis, as indicated: </p>

<blockquote><pre>
namespace std {
    // ...

    // 19.5.6 Hash support
    template&lt;class T&gt; struct hash;
    template&lt;&gt; struct hash&lt;error_code&gt;;
    <ins>template&lt;&gt; struct hash&lt;error_condition&gt;;</ins>

   // ...
}
</pre></blockquote>
</li>
<li> <p> Edit 19.5.6 [syserr.hash] as indicated: </p>

<blockquote><pre>
template &lt;&gt; struct hash&lt;error_code&gt;;
<ins>template &lt;&gt; struct hash&lt;error_condition&gt;;</ins>
</pre>

<blockquote>
<p>-1- The template specialization<ins>s</ins> shall meet the requirements of class template <tt>hash</tt> (20.12.14).</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2694" href="#2694">2694.</a> Application of LWG 436 accidentally deleted definition of "facet"</h3>
<p><b>Section:</b> 22.3.1.1.2 [locale.facet] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-04-15 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</p>
<p><b>View all other</b> <a href="lwg-index.html#locale.facet">issues</a> in [locale.facet].</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>
[locale.facet]/1 (then-called [lib.locale.facet]) read in C++03:
</p>
<blockquote>
<p>
Class <tt>facet</tt> is the base class for locale feature sets. A class is a <i>facet</i> if it is publicly derived 
from another facet, or if it is a class derived from <tt>locale::facet</tt> and containing a publicly-accessible 
declaration as follows: [<i>Footnote</i>: This is a complete list of requirements; there are no other requirements. 
Thus, a facet class need not have a public copy constructor, assignment, default constructor, destructor, etc.]
</p>
<blockquote><pre>
static ::std::locale::id id;
</pre></blockquote>
<p>
Template parameters in this clause which are required to be facets are those named <tt>Facet</tt> in declarations. 
A program that passes a type that is <em>not</em> a facet, as an (explicit or deduced) template parameter to a locale 
function expecting a facet, is ill-formed.
</p>
</blockquote>
<p>
LWG <a href="lwg-defects.html#436">436</a>'s intent appears to be to ban <tt>volatile</tt>-qualified facets and permitting 
<tt>const</tt>-qualified ones. The PR was somewhat poorly worded, however, and the editor in applying 
it deleted the whole first half of the paragraph, including the definition of <i>facet</i> and the requirement 
for a static data member named <tt>id</tt>.
<p/>
As a result, we have things like 22.3.1.1.3 [locale.id]/2 and 22.3.2 [locale.global.templates]/1 referring 
to the <tt>id</tt> member that's not defined anywhere in the working draft.
</p>

<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Insert the following paragraph before 22.3.1.1.2 [locale.facet]/1:</p>

<blockquote>
<p>
<ins>-?- Class <tt>facet</tt> is the base class for locale feature sets. A class is a <i>facet</i> if it is publicly 
derived from another facet, or if it is a class derived from <tt>locale::facet</tt> and containing a publicly accessible 
declaration as follows: [<i>Footnote</i>: This is a complete list of requirements; there are no other requirements. Thus, a 
facet class need not have a public copy constructor, assignment, default constructor, destructor, etc.]</ins>
</p>
<blockquote><pre>
<ins>static ::std::locale::id id;</ins>
</pre></blockquote>
<p>
-1- Template parameters in this Clause which are required to be facets are those named <tt>Facet</tt> in declarations. A
program that passes a type that is <i>not</i> a facet, or a type that refers to a volatile-qualified facet, as an (explicit
or deduced) template parameter to a locale function expecting a facet, is ill-formed. A const-qualified facet is
a valid template argument to any locale function that expects a Facet template parameter.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2696" href="#2696">2696.</a> Interaction between <tt>make_shared</tt> and <tt>enable_shared_from_this</tt> is underspecified</h3>
<p><b>Section:</b> 20.11.2.2.6 [util.smartptr.shared.create] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2016-04-02 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#util.smartptr.shared.create">active issues</a> in [util.smartptr.shared.create].</p>
<p><b>View all other</b> <a href="lwg-index.html#util.smartptr.shared.create">issues</a> in [util.smartptr.shared.create].</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>
For each public constructor of <tt>std::shared_ptr</tt>, the standard says that constructor <i>enables 
<tt>shared_from_this</tt></i> if that constructor is expected to initialize the internal <tt>weak_ptr</tt> 
of a contained <tt>enable_shared_from_this&lt;X&gt;</tt> object. But there are other ways to construct 
a <tt>shared_ptr</tt> than by using a public constructor. The template functions <tt>make_shared</tt> 
and <tt>allocate_shared</tt> both require calling a private constructor, since no public constructor 
can fulfill the requirement that at most one allocation is made. The standard does not specify that 
that private constructor enables <tt>shared_from_this</tt>; therefore in the following code:
</p>
<blockquote><pre>
struct Foo : public std::enable_shared_from_this&lt;Foo&gt; {};

int main() {
  auto p = std::make_shared&lt;Foo&gt;();
  assert(p == p-&gt;shared_from_this());
  return 0;
}
</pre></blockquote>
<p>
it is unspecified whether the assertion will fail.
</p>

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

<p>
Jonathan Wakely to provide updated wording.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Monday PM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Change 20.11.2.2.6 [util.smartptr.shared.create] indicated:</p>

<blockquote><pre>
template&lt;class T, class... Args&gt; shared_ptr&lt;T&gt; make_shared(Args&amp;&amp;... args);
template&lt;class T, class A, class... Args&gt;
  shared_ptr&lt;T&gt; allocate_shared(const A&amp; a, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-6- <i>Remarks</i>: <ins>The <tt>shared_ptr</tt> constructor called by this function enables <tt>shared_from_this</tt> 
with the address of the newly constructed object of type <tt>T</tt>.</ins> Implementations should perform no more than 
one memory allocation. [<i>Note</i>: This provides efficiency equivalent to an intrusive smart 
pointer. &mdash; <i>end note</i>]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2699" href="#2699">2699.</a> Missing restriction in [numeric.requirements]</h3>
<p><b>Section:</b> 26.3 [numeric.requirements] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Hubert Tong <b>Opened:</b> 2016-05-03 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>3
</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 N4582 subclause 26.3 [numeric.requirements], the "considerable flexibility in how arrays are initialized" 
do not appear to allow for replacement of calls to the default constructor with calls to the copy constructor with 
an appropriate source value.
</p>

<p><i>[2016-08-03 Chicago]</i></p>

<p>Fri AM: Moved to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>
This wording is relative to N4582.
</p>
<ol>
<li><p>Adjust 26.3 [numeric.requirements]/1 as indicated:</p>

<blockquote>
<p>
-1- The <tt>complex</tt> and <tt>valarray</tt> components are parameterized by the type of information they contain and
manipulate. [&hellip;]
</p>
<ol style="list-style-type: none">
<li><p>(1.1) &mdash; <tt>T</tt> is not an abstract class (it has no pure virtual member functions);</p></li>
<li><p>[&hellip;]</p></li>
<li><p>(1.8) &mdash; If <tt>T</tt> is a class, its assignment operator, copy and default constructors, and 
destructor shall correspond to each other in the following sense: <ins>Initialization of raw storage using 
the copy constructor on the value of <tt>T()</tt>, however obtained, is semantically equivalent to value 
initialization of the same raw storage.</ins> Initialization of raw storage using the 
default constructor, followed by assignment, is semantically equivalent to initialization of raw storage 
using the copy constructor. Destruction of an object, followed by initialization of its raw storage using 
the copy constructor, is semantically equivalent to assignment to the original object.
[<i>Note</i>: This rule states<ins>, in part,</ins> that there shall not be any subtle differences in the 
semantics of initialization versus assignment. This gives an implementation considerable flexibility in how 
arrays are initialized.
[<i>Example</i>: An implementation is allowed to initialize a <tt>valarray</tt> by allocating storage using the 
<tt>new</tt> operator (which implies a call to the default constructor for each element) and then assigning each
element its value. Or the implementation can allocate raw storage and use the copy constructor to
initialize each element. &mdash; <i>end example</i>]
If the distinction between initialization and assignment is important for a class, or if it fails to satisfy any
of the other conditions listed above, the programmer should use <tt>vector</tt> (23.3.11) instead of <tt>valarray</tt>
for that class; &mdash; <i>end note</i>]</p></li>
</ol>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2712" href="#2712">2712.</a> <tt>copy_file(from, to, ...)</tt> has a number of unspecified error conditions</h3>
<p><b>Section:</b> 27.10.15.4 [fs.op.copy_file] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-05-10 <b>Last modified:</b> 2016-08-08</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>
There are a number of error cases that <tt>copy_file(from, to, ...)</tt> does not take into account.
Specifically the cases where:
</p>
<ol style="list-style-type:upper-alpha">
<li><tt>from</tt> does not exist</li>
<li><tt>from</tt> is not a regular file</li>
<li><tt>to</tt> exists and is not a regular file</li>
</ol>
<p>
These error cases should be specified as such.
</p>

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

<p>
Eric to provide wording.
</p>

<p><i>[2016-05-28, Eric Fiselier provides wording]</i></p>


<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4582.</p>
<ol>
<li><p>Modify 27.10.15.4 [fs.op.copy_file] as indicated:</p>

<blockquote>
<pre>
bool copy_file(const path&amp; from, const path&amp; to, copy_options options);
bool copy_file(const path&amp; from, const path&amp; to, copy_options options,
               error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-3- <i>Requires:</i> At most one constant from each <tt>copy_options</tt> option group (27.10.10.2) is present in
<tt>options</tt>.
<p/>
-4- <i>Effects:</i> Report a file already exists error as specified in Error reporting (27.5.6.5) if:
</p>
<ul>
<li><ins><tt>!is_regular_file(from)</tt>, or</ins></li>
<li><ins><tt>exists(to)</tt> and <tt>!is_regular_file(to)</tt>, or</ins></li>
<li><tt>exists(to)</tt> and <tt>equivalent(from, to)</tt>, or</li>
<li><tt>exists(to)</tt> and <tt>(options &amp; (copy_options::skip_existing | copy_options::overwrite_existing | 
copy_options::update_existing)) == copy_options::none</tt>.</li>
</ul>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2722" href="#2722">2722.</a> <tt>equivalent</tt> incorrectly specifies throws clause</h3>
<p><b>Section:</b> 27.10.15.13 [fs.op.equivalent] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Eric Fiselier <b>Opened:</b> 2016-05-28 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</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 spec for <tt>equivalent</tt> has a throws clause which reads: [fs.op.equivalent]/5
</p>
<blockquote>
<p>
<i>Throws:</i> <tt>filesystem_error</tt> if <tt>(!exists(s1) &amp;&amp; !exists(s2)) || (is_other(s1) 
&amp;&amp; is_other(s2))</tt>, otherwise as specified in Error reporting (27.10.7).
</p>
</blockquote>
<p>
This explicit requirement to throw is incorrect for the <tt>equivalent</tt> overload which takes an <tt>error_code</tt>.
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to N4582.</p>
<ol>
<li><p>Modify 27.10.15.13 [fs.op.equivalent] as follows:</p>

<blockquote>
<pre>
bool equivalent(const path&amp; p1, const path&amp; p2);
bool equivalent(const path&amp; p1, const path&amp; p2, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Determines <tt>file_status s1</tt> and <tt>s2</tt>, as if by <tt>status(p1)</tt> and 
<tt>status(p2)</tt>, respectively.
<p/>
-2- <i>Returns:</i> <ins>If <tt>(!exists(s1) &amp;&amp; !exists(s2)) || (is_other(s1) &amp;&amp; is_other(s2))</tt> 
an error is reported (27.10.7 [fs.err.report]). Otherwise</ins> <tt>true</tt>, if <tt>s1 == s2</tt> and 
<tt>p1</tt> and <tt>p2</tt> resolve to the same file system entity, else <tt>false</tt>. The signature with argument 
<tt>ec</tt> returns <tt>false</tt> if an error occurs.
<p/>
-3- Two paths are considered to resolve to the same file system entity if two candidate entities reside on the
same device at the same location. This is determined as if by the values of the POSIX <tt>stat</tt> structure,
obtained as if by <tt>stat()</tt> for the two paths, having equal <tt>st_dev</tt> values and equal <tt>st_ino</tt> values.
<p/>
-4- <i>Throws:</i> <del><tt>filesystem_error</tt> if <tt>(!exists(s1) &amp;&amp; !exists(s2)) || (is_other(s1) &amp;&amp; 
is_other(s2))</tt>, otherwise a</del><ins>A</ins>s specified in <del>E</del><ins>e</ins>rror reporting 
(27.10.7 [fs.err.report]).
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-06 Oulu &mdash; Daniel provides wording improvements]</i></p>

<p>
mc: do we have an error reporting clause?<br/>
jw: there is no such clause<br/>
gr: it should go into the effects clause<br/>
dk: we have the same issue for <tt>file_size</tt><br/>
dk: the right place is the effects clause
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Modify 27.10.15.13 [fs.op.equivalent] as follows:</p>

<blockquote>
<pre>
bool equivalent(const path&amp; p1, const path&amp; p2);
bool equivalent(const path&amp; p1, const path&amp; p2, error_code&amp; ec) noexcept;
</pre>
<blockquote>
<p>
-1- Let <tt>s1</tt> and <tt>s2</tt> be <tt>file_status</tt>s, determined as if by <tt>status(p1)</tt> and <tt>status(p2)</tt>, respectively.
<p/>
-2- <i>Effects:</i> Determines <tt>s1</tt> and <tt>s2</tt>. <ins>If <tt>(!exists(s1) &amp;&amp; !exists(s2)) || 
(is_other(s1) &amp;&amp; is_other(s2))</tt> an error is reported (27.10.7 [fs.err.report]).</ins>
<p/>
-3- <i>Returns:</i> <tt>true</tt>, if <tt>s1 == s2</tt> and 
<tt>p1</tt> and <tt>p2</tt> resolve to the same file system entity, else <tt>false</tt>. The signature with argument 
<tt>ec</tt> returns <tt>false</tt> if an error occurs.
<p/>
-4- Two paths are considered to resolve to the same file system entity if two candidate entities reside on the
same device at the same location. This is determined as if by the values of the POSIX <tt>stat</tt> structure,
obtained as if by <tt>stat()</tt> for the two paths, having equal <tt>st_dev</tt> values and equal <tt>st_ino</tt> values.
<p/>
-5- <i>Throws:</i> <del><tt>filesystem_error</tt> if <tt>(!exists(s1) &amp;&amp; !exists(s2)) || (is_other(s1) &amp;&amp; 
is_other(s2))</tt>, otherwise a</del><ins>A</ins>s specified in <del>E</del><ins>e</ins>rror reporting 
(27.10.7 [fs.err.report]).
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2729" href="#2729">2729.</a> Missing SFINAE on <tt>std::pair::operator=</tt></h3>
<p><b>Section:</b> 20.4.2 [pairs.pair], 20.5.2.2 [tuple.assign] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-06-07 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#pairs.pair">active issues</a> in [pairs.pair].</p>
<p><b>View all other</b> <a href="lwg-index.html#pairs.pair">issues</a> in [pairs.pair].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::is_copy_assignable&lt;std::pair&lt;int, std::unique_ptr&lt;int&gt;&gt;&gt;::value</tt> is <tt>true</tt>, and 
should be <tt>false</tt>. We're missing a "shall not participate in overload resolution unless" for <tt>pair</tt>'s 
<tt>operator=</tt>, and likewise for <tt>tuple</tt>.
</p>

<p><i>[2016-08-03 Chicago LWG]</i></p>

<p>
Inspired by Eric Fiselier and Ville, Walter and Nevin provide initial Proposed Resolution.
</p>

<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs PM: Moved to Tentatively Ready</p>
<p>Lots of discussion, but no one had a better idea.</p>


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

<ol>
<li><p>Change 20.4.2 [pairs.pair] as indicated:</p>

<blockquote>
<pre>
pair&amp; operator=(const pair&amp; p);
</pre>
<blockquote>
<p>
-15- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall be defined as deleted unless</ins> 
<tt>is_copy_assignable_v&lt;first_type&gt;</tt> is <tt>true</tt> and 
<tt>is_copy_assignable_v&lt;second_type&gt;</tt> is <tt>true</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class U, class V&gt; pair&amp; operator=(const pair&lt;U, V&gt;&amp; p);
</pre>
<blockquote>
<p>
-18- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>is_assignable_v&lt;first_type&amp;, const U&amp;&gt;</tt> is <tt>true</tt> and 
<tt>is_assignable_v&lt;second_type&amp;, const V&amp;&gt;</tt> is <tt>true</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
pair&amp; operator=(pair&amp;&amp; p) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-21- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:
</p>
<blockquote><pre>
is_nothrow_move_assignable_v&lt;T1&gt; &amp;&amp; is_nothrow_move_assignable_v&lt;T2&gt;
</pre></blockquote>
<p>
-22- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall be defined as deleted unless</ins> 
<tt>is_move_assignable_v&lt;first_type&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;second_type&gt;</tt> is <tt>true</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class U, class V&gt; pair&amp; operator=(pair&lt;U, V&gt;&amp;&amp; p);
</pre>
<blockquote>
<p>
-25- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>is_assignable_v&lt;first_type&amp;, U&amp;&amp;&gt;</tt> is <tt>true</tt> and 
<tt>is_assignable_v&lt;second_type&amp;, V&amp;&amp;&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.5.2.2 [tuple.assign] as indicated:</p>

<blockquote>
<pre>
tuple&amp; operator=(const tuple&amp; u);
</pre>
<blockquote>
<p>
-2- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall be defined as deleted unless</ins> 
<tt>is_copy_assignable_v&lt;T<sub><i>i</i></sub>&gt;</tt> is <tt>true</tt> for all <tt><i>i</i></tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
tuple&amp; operator=(tuple&amp;&amp; u) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-5- <i>Remark:</i> The expression inside <tt>noexcept</tt> is equivalent to the logical AND of the following expressions:
</p>
<blockquote><pre>
is_nothrow_move_assignable_v&lt;T<sub><i>i</i></sub>&gt;
</pre></blockquote>
<p>
where <tt>T<sub><i>i</i></sub></tt> is the <tt><i>i<sup>th</sup></i></tt> type in <tt>Types</tt>.
<p/>
-6- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall be defined as deleted unless</ins>
<tt>is_move_assignable_v&lt;T<sub><i>i</i></sub>&gt;</tt> is <tt>true</tt> for all <tt><i>i</i></tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class... UTypes&gt;
  tuple&amp; operator=(const tuple&lt;UTypes...&gt;&amp; u);
</pre>
<blockquote>
<p>
-9- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>sizeof...(Types) == sizeof...(UTypes)</tt> and 
<tt>is_assignable_v&lt;T<sub><i>i</i></sub>&amp;, const U<sub><i>i</i></sub>&amp;&gt;</tt> is <tt>true</tt> 
for all <tt><i>i</i></tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class... UTypes&gt;
  tuple&amp; operator=(tuple&lt;UTypes...&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
-12- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>is_assignable_v&lt;T<sub><i>i</i></sub>&amp;, U<sub><i>i</i></sub>&amp;&amp;&gt; == true</tt> 
for all <tt><i>i</i></tt><del>.</del> <ins>and</ins> <tt>sizeof...(Types) == sizeof...(UTypes)</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class U1, class U2&gt; tuple&amp; operator=(const pair&lt;U1, U2&gt;&amp; u);
</pre>
<blockquote>
<p>
-15- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>sizeof...(Types) == 2</tt><del>.</del> <ins>and</ins> <tt>is_assignable_v&lt;T<sub><i>0</i></sub>&amp;, 
const U<sub><i>1</i></sub>&amp;&gt;</tt> is <tt>true</tt> for the first type <tt>T<sub><i>0</i></sub></tt> in 
<tt>Types</tt> and <tt>is_assignable_v&lt;T<sub><i>1</i></sub>&amp;, const U<sub><i>2</i></sub>&amp;&gt;</tt> 
is <tt>true</tt> for the second type <tt>T<sub><i>1</i></sub></tt> in <tt>Types</tt>.
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template &lt;class U1, class U2&gt; tuple&amp; operator=(pair&lt;U1, U2&gt;&amp;&amp; u);
</pre>
<blockquote>
<p>
-18- <i><del>Requires</del><ins>Remarks</ins>:</i> <ins>This operator shall not participate in overload resolution 
unless</ins> <tt>sizeof...(Types) == 2</tt><del>.</del> <ins>and</ins> <tt>is_assignable_v&lt;T<sub><i>0</i></sub>&amp;, 
U<sub><i>1</i></sub>&amp;&amp;&gt;</tt> is <tt>true</tt> for the first type <tt>T<sub><i>0</i></sub></tt> in 
<tt>Types</tt> and <tt>is_assignable_v&lt;T<sub><i>1</i></sub>&amp;, U<sub><i>2</i></sub>&amp;&amp;&gt;</tt> 
is <tt>true</tt> for the second type <tt>T<sub><i>1</i></sub></tt> in <tt>Types</tt>.
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2732" href="#2732">2732.</a> Questionable specification of <tt>path::operator/=</tt> and <tt>path::append</tt></h3>
<p><b>Section:</b> 27.10.8.4.3 [path.append] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-06-14 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>2
</p>
<p><b>View other</b> <a href="lwg-index-open.html#path.append">active issues</a> in [path.append].</p>
<p><b>View all other</b> <a href="lwg-index.html#path.append">issues</a> in [path.append].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The current specification of <tt>operator/=</tt> taking a <tt>const Source&amp;</tt> parameter, and of 
<tt>path::append</tt> in 27.10.8.4.3 [path.append] appears to require <tt>Source</tt> to have a <tt>native()</tt> 
and an <tt>empty()</tt> member, and seemingly requires different behavior for <tt>append(<i>empty_range</i>)</tt> 
and <tt>append(first, last)</tt> when <tt>first == last</tt> (the last two bullet points being specified with 
<tt>source</tt> alone), which doesn't make any sense.
<p/>
It appears that these overloads can just be specified using the <tt>operator/=(const path&amp;)</tt> overload.
</p>

<p><i>[2016-07-03, Daniel comments]</i></p>

<p>
The same wording area is affected by LWG <a href="lwg-active.html#2664">2664</a>.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed AM: Move to Tentatively Ready</p>

<p>Friday AM, in discussing <a href="lwg-active.html#2664">2664</a> a comment about missing "equivalent to" language
was made, so PR updated.</p>

<p><strong>Previous Resolution [SUPERSEDED]</strong></p>
<blockquote class="note">
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Edit 27.10.8.4.3 [path.append]/4-5 as indicated:</p>

<blockquote>
<pre>
template &lt;class Source&gt;
  path&amp; operator/=(const Source&amp; source);
template &lt;class Source&gt;
  path&amp; append(const Source&amp; source);
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> <tt>operator/=(path(source))</tt></ins>
<p/>
<ins>-?- <i>Returns:</i> <tt>*this</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class InputIterator&gt;
  path&amp; append(InputIterator first, InputIterator last);
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> <del>Appends <tt>path::preferred_separator</tt> to <tt>pathname</tt>, converting format and encoding
if required (27.10.8.2 [path.cvt]), unless:</del>
</p>
<ul>
<li><p><del>an added <i>directory-separator</i> would be redundant, or</del></p></li>
<li><p><del>an added <i>directory-separator</i> would change an relative path to an absolute path, or</del></p></li>
<li><p><del><tt>source.empty()</tt> is <tt>true</tt>, or</del></p></li>
<li><p><del><tt>*source.native().cbegin()</tt> is a <i>directory-separator</i>.</del></p></li>
</ul>
<p>
<del>Then appends the effective range of <tt>source</tt> (27.10.8.3 [path.req]) or the range <tt>[first, last)</tt> to
<tt>pathname</tt>, converting format and encoding if required
(27.10.8.2 [path.cvt])</del><ins><tt>operator/=(path(first, last))</tt></ins>.
<p/>
-5- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4606.</p>
<ol>
<li><p>Edit 27.10.8.4.3 [path.append]/4-5 as indicated:</p>

<blockquote>
<pre>
template &lt;class Source&gt;
  path&amp; operator/=(const Source&amp; source);
template &lt;class Source&gt;
  path&amp; append(const Source&amp; source);
</pre>
<blockquote>
<p><ins>-?- <i>Effects:</i> Equivalent to <tt>return operator/=(path(source));</tt>.</ins></p>
</blockquote>
<pre>
template &lt;class InputIterator&gt;
  path&amp; append(InputIterator first, InputIterator last);
</pre>
<blockquote>
<p>-4- <i>Effects:</i> <ins>Equivalent to <tt>return operator/=(path(first, last));</tt>.</ins><del>Appends <tt>path::preferred_separator</tt> to <tt>pathname</tt>,
converting format and encoding if required (27.10.8.2 [path.cvt]), unless:</del></p>
<ol style="list-style-type: none">
<li><del>&mdash; an added <i>directory-separator</i> would be redundant, or</del></li>
<li><del>&mdash; an added <i>directory-separator</i> would change an relative path to an absolute
path, or</del></li>
<li><del>&mdash; <tt>source.empty()</tt> is <tt>true</tt>, or</del></li>
<li><del>&mdash; <tt>*source.native().cbegin()</tt> is a <i>directory-separator</i>.</del></li>
</ol>
<p><del>Then appends the effective range of <tt>source</tt> (27.10.8.3 [path.req]) or the
range <tt>[first, last)</tt> to <tt>pathname</tt>, converting format and encoding if required
(27.10.8.2 [path.cvt]).</del></p>
<p><del>-5- <i>Returns:</i> <tt>*this</tt>.</del></p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2733" href="#2733">2733.</a> [fund.ts.v2] <tt>gcd</tt> / <tt>lcm</tt> and <tt>bool</tt></h3>
<p><b>Section:</b> 99 [fund.ts.v2::numeric.ops.gcd], 99 [fund.ts.v2::numeric.ops.lcm] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-06-15 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>4
</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>
According to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2015/n4562.html">N4562</a>, <tt>gcd</tt> and 
<tt>lcm</tt> support <tt>bool</tt> as the operand type. The wording doesn't appear to cover the behavior for that case, 
since <tt>bool</tt> does not have a zero value and <tt>gcd</tt> / <tt>lcm</tt> are not normally mathematically defined 
over <tt>{false, true}</tt>.
<p/>
Presumably <tt>gcd</tt> and <tt>lcm</tt> shouldn't accept arguments of type <tt>bool</tt>.
</p>

<p><i>[2016-08-01, Walter Brown suggests wording]</i></p>

<p>
A corresponding issue has been added addressing the WP, see LWG <a href="lwg-active.html#2759">2759</a>.
</p>

<p><i>[2016-08, Chicago]</i></p>

<p>Monday PM: Moved to Tentatively Ready</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/2016/n4600.html">N4600</a>.</p>

<ol>
<li><p>Adjust 99 [numeric.ops.gcd] p3 as indicated:</p>

<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; gcd(M m, N n);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Remarks:</i> If either <tt>M</tt> or <tt>N</tt> is not an integer type, <ins>or if either is (possibly <i>cv</i>-qualified) 
<tt>bool</tt>,</ins> the program is ill-formed. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Adjust 99 [numeric.ops.lcm] p3 as indicated:</p>

<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; lcm(M m, N n);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Remarks:</i> If either <tt>M</tt> or <tt>N</tt> is not an integer type, <ins>or if either is (possibly <i>cv</i>-qualified) 
<tt>bool</tt>,</ins> the program is ill-formed. 
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2735" href="#2735">2735.</a> <tt>std::abs(short)</tt>, <tt>std::abs(signed char)</tt> and others should return <tt>int</tt> instead of 
<tt>double</tt> in order to be compatible with C++98 and C</h3>
<p><b>Section:</b> 26.9 [c.math] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> J&ouml;rn Heusipp <b>Opened:</b> 2016-06-16 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#c.math">active issues</a> in [c.math].</p>
<p><b>View all other</b> <a href="lwg-index.html#c.math">issues</a> in [c.math].</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>
Consider this C++98 program:
</p>
<blockquote>
<pre>
#include &lt;cmath&gt;
#include &lt;cstdlib&gt;

int main() {
  return std::abs(static_cast&lt;short&gt;(23)) % 42;
}
</pre>
</blockquote>
<p>
This works fine with C++98 compilers. At the <tt>std::abs(short)</tt> call, short gets promoted to <tt>int</tt> and 
<tt>std::abs(int)</tt> is called.
<p/>
C++11 added the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4594.pdf">following wording</a>
on page 1083 &sect;26.9 p15 b2 [c.math]:
</p>
<blockquote>
<p>
Otherwise, if any argument of arithmetic type corresponding to a <tt>double</tt> parameter has type <tt>double</tt> 
or an integer type, then all arguments of arithmetic type corresponding to <tt>double</tt> parameters are effectively 
cast to <tt>double</tt>.
</p>
</blockquote>
<p>
C++17 draft <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/n4594.pdf">additionally adds</a> on
page 1080 &sect;26.9 p10 [c.math]:
</p>
<blockquote>
<p>
If <tt>abs()</tt> is called with an argument of type <tt>X</tt> for which <tt>is_unsigned&lt;X&gt;::value</tt> is <tt>true</tt> 
and if <tt>X</tt> cannot be converted to <tt>int</tt> by integral promotion (4.5), the program is ill-formed. [<i>Note:</i> 
Arguments that can be promoted to <tt>int</tt> are permitted for compatibility with C. &mdash; <i>end note</i>]
</p>
</blockquote>
<p>
It is somewhat confusing and probably even contradictory to on the one hand specify <tt>abs()</tt> in terms of integral 
promotion in &sect;26.9 p10 and on the other hand demand all integral types to be converted to <tt>double</tt> in 
&sect;26.9 p15 b2.
<p/>
Most compilers (each with their own respective library implementation) I tested (MSVC, Clang, older GCC) appear to not 
consider &sect;26.9 p15 b2 for <tt>std::abs</tt> and compile the code successfully. GCC 4.5-5.3 (for <tt>std::abs</tt> but 
not for <tt>::abs</tt>) as well as GCC &gt;=6.0 (for both <tt>std::abs</tt> and <tt>::abs</tt>) fail to compile in the following 
way: Taking &sect;26.9 p15 b2 literally and applying it to <tt>abs()</tt> (which is listed in &sect;26.9 p12) results in 
<tt>abs(short)</tt> returning <tt>double</tt>, and with <tt>operator%</tt> not being specified for <tt>double</tt>, this 
makes the programm ill-formed.
<p/>
I do acknowledge the reason for the wording and semantics demanded by &sect;26.9 p15 b2, i.e. being able to call math functions 
with integral types or with partly floating point types and partly integral types. Converting integral types to <tt>double</tt>
certainly makes sense here for all the other floating point math functions.
However, <tt>abs()</tt> is special. <tt>abs()</tt> has overloads for the 3 wider integral types which return integral types. 
<tt>abs()</tt> originates in the C standard in <tt>stdlib.h</tt> and had originally been specified for integral types only. 
Calling it in C with a short argument returns an <tt>int</tt>. Calling <tt>std::abs(short)</tt> in C++98 also returns an 
<tt>int</tt>. Calling <tt>std::abs(short)</tt> in C++11 and later with &sect;26.9 p15 b2 applied to <tt>abs()</tt> suddenly 
returns a <tt>double</tt>.
<p/>
Additionally, this behaviour also breaks third-party C headers which contain macros or inline functions calling 
<tt>abs(short)</tt>.
<p/>
As per discussion on std-discussion, my reading of the standard as well as GCC's interpretation seem valid.
However, as can be seen, this breaks existing code.
<p/>
In addition to the compatibilty concerns, having <tt>std::abs(short)</tt> return <tt>double</tt> is also very confusing 
and unintuitive.
<p/>
The other (possibly, depending on their respective size relative to <tt>int</tt>) affected types besides <tt>short</tt> 
are <tt>signed char</tt>, <tt>unsigned char</tt> and <tt>unsigned short</tt>, and also <tt>char</tt>, <tt>char16_t</tt>, 
<tt>char32_t</tt> and <tt>wchar_t</tt>, (all of these are or may be promotable to <tt>int</tt>). Wider integral types 
are not affected because explicit overloads are specified for those types by &sect;26.9 p6, &sect;26.9 p7 and &sect;26.9 p9.
<tt>div()</tt> is also not affected because it is neither listed in &sect;26.9 p12, nor does it actually provide 
any overload for <tt>double</tt> at all.
<p/>
As far as I can see, the proposed or implemented solutions for LWG <a href="lwg-active.html#2294">2294</a>, <a href="lwg-defects.html#2192">2192</a> and/or 
<a href="lwg-defects.html#2086">2086</a> do not resolve this issue.
<p/>
I think both, &sect;26.9 p10 [c.math] and &sect;26.9 p15 [c.math] need some correction and clarification.
<p/>
(Note: These changes would explicitly render the current implementation in GCC's libstdc++ non-conforming, which would 
be a good thing, as outlined above.)
</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>This wording is relative to N4594.</p>
<ol>
<li><p>Modify 26.9 [c.math] as indicated:</p>

<blockquote>
<p>
-10- If <tt>abs()</tt> is called with an argument of type <tt>X</tt> for which <tt>is_unsigned&lt;X&gt;::value</tt> is 
<tt>true</tt> and if <tt>X</tt> cannot be converted to <tt>int</tt> by integral promotion (4.5), the program is ill-formed.
<ins>If <tt>abs()</tt> is called with an argument of type <tt>X</tt> which can be converted to <tt>int</tt> by integral 
promotion (4.5), the argument is promoted to <tt>int</tt>.</ins> [<i>Note:</i> Arguments that can be promoted to <tt>int</tt> 
are <ins>promoted to <tt>int</tt> in order to keep</ins><del>permitted for</del> compatibility with C. &mdash; <i>end note</i>]
<p/>
[&hellip;]
<p/>
-15- Moreover, there shall be additional overloads <ins>for these functions, with the exception of <tt>abs()</tt>,</ins> 
sufficient to ensure:
</p>
<ol>
<li><p>If any argument of arithmetic type corresponding to a <tt>double</tt> parameter has type <tt>long double</tt>, then
all arguments of arithmetic type (3.9.1) corresponding to <tt>double</tt> parameters are effectively cast to
<tt>long double</tt>.</p></li>
<li><p>Otherwise, if any argument of arithmetic type corresponding to a <tt>double</tt> parameter has type <tt>double</tt>
or an integer type, then all arguments of arithmetic type corresponding to <tt>double</tt> parameters are
effectively cast to <tt>double</tt>.</p></li>
<li><p>Otherwise, all arguments of arithmetic type corresponding to <tt>double</tt> parameters have type <tt>float</tt>.</p></li>
</ol>
<p>
See also: ISO C 7.5, 7.10.2, 7.10.6.
<p/>
<ins>[<i>Note:</i> <tt>abs()</tt> is exempted from these rules in order to stay compatible with C. &mdash; <i>end note</i>]</ins>
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-07 Chicago]</i></p>

<p>Monday: Some of this has been changed in N4606; the rest of the changes may be editorial.</p>
<p>Fri PM: Move to Tentatively Ready</p>



<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4606.</p>
<ol>
<li><p>Modify 26.9.1 [cmath.syn] as indicated:</p>

<blockquote>
<p>
-2- For each set of overloaded functions within <tt>&lt;cmath&gt;</tt>,
 <ins>with the exception of <tt>abs</tt>, </ins> there shall be additional
overloads sufficient to ensure:
</p>
<ol>
<li><p>If any argument of arithmetic type corresponding to a <tt>double</tt> parameter has type <tt>long double</tt>, then
all arguments of arithmetic type (3.9.1) corresponding to <tt>double</tt> parameters are effectively cast to
<tt>long double</tt>.</p></li>
<li><p>Otherwise, if any argument of arithmetic type corresponding to a <tt>double</tt> parameter has type <tt>double</tt>
or an integer type, then all arguments of arithmetic type corresponding to <tt>double</tt> parameters are
effectively cast to <tt>double</tt>.</p></li>
<li><p>Otherwise, all arguments of arithmetic type corresponding to <tt>double</tt> parameters have type <tt>float</tt>.</p></li>
</ol>
<p><ins>[<i>Note:</i> <tt>abs</tt> is exempted from these rules in order to stay compatible with C. &mdash; <i>end note</i>]</ins></p>
<p>
See also: ISO C 7.5, 7.10.2, 7.10.6.
</p>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2736" href="#2736">2736.</a> <tt>nullopt_t</tt> insufficiently constrained</h3>
<p><b>Section:</b> 20.6.4 [optional.nullopt] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Tim Song <b>Opened:</b> 2016-06-17 <b>Last modified:</b> 2016-08-08</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>
20.6.4 [optional.nullopt]/2 requires of <tt>nullopt_t</tt> that
</p>
<blockquote>
<p>
Type <tt>nullopt_t</tt> shall not have a default constructor. It shall be a literal type. Constant <tt>nullopt</tt> shall 
be initialized with an argument of literal type.
</p>
</blockquote>
<p>
This does not appear sufficient to foreclose the following implementation:
</p>
<blockquote>
<pre>
struct nullopt_t 
{
  constexpr nullopt_t(const nullopt_t&amp;) = default;
};

constexpr nullopt_t nullopt(nullopt_t{});
</pre>
</blockquote>
<ul>
<li><tt>nullopt_t</tt> has no default constructor because it has a user-declared (copy) constructor;</li>
<li><tt>nullopt_t</tt> has a trivial destructor, is an aggregate, and is a literal type;</li>
<li><tt>nullopt</tt> has been initialized with an argument of literal type, to wit, <tt>nullopt_t</tt>.</li>
</ul>
<p>
But such a <tt>nullopt_t</tt> is still constructible from <tt>{}</tt> and so still makes <tt>opt = {}</tt> ambiguous.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>This is related to LWG <a href="lwg-active.html#2510">2510</a>.</p>
<p>Monday PM: Ville to provide updated wording</p>
<p>Fri AM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Edit 20.6.4 [optional.nullopt]/2 as indicated:</p>
<blockquote class="note">
<p>
[<i>Drafting note</i>: <tt>{}</tt> can do one of three things for a class type:
it may be aggregate initialization, it may call a default constructor,
or it may call an initializer-list constructor (see 8.6.4 [dcl.init.list], 13.3.1.7 [over.match.list]).
The wording below forecloses all three possibilities. &mdash; <i>end drafting note</i>]
</p>
</blockquote>
<blockquote>
<p>
-2- Type <tt>nullopt_t</tt> shall not have a default constructor <ins>or an initializer-list constructor</ins>. 
It <ins>shall not be an aggregate and</ins> shall be a literal type. Constant <tt>nullopt</tt> shall 
be initialized with an argument of literal type.
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2738" href="#2738">2738.</a> <tt>is_constructible</tt> with <tt>void</tt> types</h3>
<p><b>Section:</b> 20.15.4.3 [meta.unary.prop] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> S. B. Tam <b>Opened:</b> 2016-06-22 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#meta.unary.prop">active issues</a> in [meta.unary.prop].</p>
<p><b>View all other</b> <a href="lwg-index.html#meta.unary.prop">issues</a> in [meta.unary.prop].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2560">2560</a> mention that there is no variable of function type. There's also no variable of <tt>void</tt> type, 
so should 20.15.4.3 [meta.unary.prop] also explicitly say that for a <tt>void</tt> type <tt>T</tt>, 
<tt>is_constructible&lt;T, Args...&gt;::value</tt> is <tt>false</tt>?
</p>

<p><i>[2016-07-03, Daniel provides wording]</i></p>


<p><i>[2016-08 Chicago]</i></p>

<p>Wed PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 20.15.4.3 [meta.unary.prop], Table 52 &mdash; "Type property predicates", as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 52 &mdash; Type property predicates</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Preconditions</th>
</tr>

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

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

<td>
For a function type <tt>T</tt><br/> 
<ins>or for a (possibly <i>cv</i>-qualified) <tt>void</tt> type <tt>T</tt></ins>,<br/> 
<tt>is_constructible&lt;T, Args...&gt;::value</tt><br/>
is <tt>false</tt>, otherwise <i>see below</i>
</td>

<td align="center">
<tt>T</tt> and all types in the<br/>
parameter pack <tt>Args</tt> shall<br/>
be complete types,<br/>
(possibly <i>cv</i>-qualified)<br/>
<tt>void</tt>, or arrays of<br/>
unknown bound.
</td>
</tr>

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

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






<hr>
<h3><a name="2739" href="#2739">2739.</a> Issue with <tt>time_point</tt> non-member subtraction with an unsigned duration</h3>
<p><b>Section:</b> 20.17.6.5 [time.point.nonmember] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Michael Winterberg <b>Opened:</b> 2016-06-23 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#time.point.nonmember">issues</a> in [time.point.nonmember].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
In N4594, 20.17.6.5 [time.point.nonmember], <tt>operator-(time_point, duration)</tt> is specified as:
</p>
<blockquote>
<pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
  constexpr time_point&lt;Clock, common_type_t&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;&gt;
  operator-(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> <tt>lhs + (-rhs)</tt>.
</p>
</blockquote>
</blockquote>
<p>
When <tt>Rep2</tt> is an unsigned integral type, the behavior is quite different with arithmetic of the underlying 
integral types because of the requirement to negate the incoming duration and then add that. It also ends up 
producing different results than the underlying durations as well as the non-member <tt>time_point::operator-=</tt>.
<p/>
Consider this program:
</p>
<blockquote>
<pre>
#include &lt;chrono&gt;
#include &lt;iostream&gt;
#include &lt;cstdint&gt;

using namespace std;
using namespace std::chrono;

int main()
{
  const duration&lt;uint32_t&gt; unsignedSeconds{5};

  auto someValue = system_clock::from_time_t(200);
  cout &lt;&lt; system_clock::to_time_t(someValue) &lt;&lt; '\n';
  cout &lt;&lt; system_clock::to_time_t(someValue - unsignedSeconds) &lt;&lt; '\n';
  someValue -= unsignedSeconds;
  cout &lt;&lt; system_clock::to_time_t(someValue) &lt;&lt; '\n';

  std::chrono::seconds signedDur{200};
  cout &lt;&lt; signedDur.count() &lt;&lt; '\n';
  cout &lt;&lt; (signedDur - unsignedSeconds).count() &lt;&lt; '\n';
  signedDur -= unsignedSeconds;
  cout &lt;&lt; signedDur.count() &lt;&lt; '\n';
}
</pre>
</blockquote>
<p>
The goal of the program is to compare the behavior of <tt>time_point</tt> non-member <tt>operator-</tt>, 
<tt>time_point</tt> member <tt>operator-=</tt>, <tt>duration</tt> non-member <tt>operator-</tt>, and 
<tt>duration</tt> member <tt>operator-=</tt> with basically the same inputs.
<p/>
libc++ produces this output, which appears mandated by the standard:
</p>
<blockquote>
<pre>
200
4294967491
195
200
195
195
</pre>
</blockquote>
<p>
On the other hand, libstdc++ produces this output, which is what I "intuitively" expect and behaves more consistently:
</p>
<blockquote>
<pre>
200
195
195
200
195
195
</pre>
</blockquote>
<p>
Given the seemingly brief coverage of durations with unsigned representations in the standard, this seems to be an 
oversight rather than a deliberate choice for this behavior. Additionally, there may be other "unexpected" behaviors 
with durations with an unsigned representation, this is just the one that I've come across.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Change 20.17.6.5 [time.point.nonmember] as indicated:</p>

<blockquote>
<pre>
template &lt;class Clock, class Duration1, class Rep2, class Period2&gt;
  constexpr time_point&lt;Clock, common_type_t&lt;Duration1, duration&lt;Rep2, Period2&gt;&gt;&gt;
  operator-(const time_point&lt;Clock, Duration1&gt;&amp; lhs, const duration&lt;Rep2, Period2&gt;&amp; rhs);
</pre>
<blockquote>
<p>
-3- <i>Returns:</i> <del><tt>lhs + (-rhs)</tt></del><ins><tt><i>CT</i>(lhs.time_since_epoch() - rhs)</tt>, where 
<tt><i>CT</i></tt> is the type of the return value</ins>.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2740" href="#2740">2740.</a> <tt>constexpr optional&lt;T&gt;::operator-&gt;</tt></h3>
<p><b>Section:</b> 20.6.3.5 [optional.object.observe] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2016-07-02 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>optional&lt;T&gt;::operator-&gt;</tt>s are constrained to be <tt>constexpr</tt> functions
only when <tt>T</tt> is not a type with an overloaded unary <tt>operator&amp;</tt>. This
constrain comes from the need to use <tt>addressof</tt> (or a similar
mechanism), and the inability to do so in a constant expression in
C++14. Given that <tt>addressof</tt> is now <tt>constexpr</tt>, this constrain is no
longer needed.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Modify 20.6.3.5 [optional.object.observe] as indicated:</p>

<blockquote>
<pre>
constexpr T const* operator-&gt;() const;
constexpr T* operator-&gt;();
</pre>
<blockquote>
<p>
-1- <i>Requires:</i> <tt>*this</tt> contains a value.
<p/>
-2- <i>Returns:</i> <tt>val</tt>.
<p/>
-3- <i>Throws:</i> Nothing.
<p/>
-4- <i>Remarks:</i> <del>Unless <tt>T</tt> is a user-defined type with overloaded unary <tt>operator&amp;</tt>, 
t</del><ins>T</ins>hese functions shall be <tt>constexpr</tt> functions.
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2742" href="#2742">2742.</a> Inconsistent <tt>string</tt> interface taking <tt>string_view</tt></h3>
<p><b>Section:</b> 21.3.1.2 [string.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-07-06 <b>Last modified:</b> 2016-08-06</p>
<p><b>Priority: </b>1
</p>
<p><b>View all other</b> <a href="lwg-index.html#string.cons">issues</a> in [string.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Generally, <tt>basic_string</tt> has a constructor matching each <tt>assign</tt> function and vice versa (except the 
constructor takes an allocator where <tt>assign</tt> does not). <a href="http://wg21.link/p0254r2">P0254R2</a> violates 
this by adding an <tt>assign(basic_string_view, size_type pos, size_type n = npos)</tt> but no corresponding constructor.
</p>

<p><i>[2016-08-04 Chicago LWG]</i></p>

<p>
Robert Douglas provides initial wording.
<p/>
We decided against another constructor overload to avoid the semantic confusion between:
</p>
<blockquote><pre>
basic_string(char const*, size_type length, Allocator = Allocator())
</pre></blockquote>
<p>
and
</p>
<blockquote><pre>
template&lt;class T, class Foo = is_convertible_v&lt;T const&amp;, basic_string_view&lt;charT, traits&gt;&gt;
basic_string(T const&amp;, size_type pos, Allocator = Allocator())
</pre></blockquote>
<p>
where someone might call:
</p>
<blockquote><pre>
basic_string("HelloWorld", 5, 5);
</pre></blockquote>
<p>
and get "World", but then call
</p>
<blockquote><pre>
basic_string("HelloWorld", 5);
</pre></blockquote>
<p>
and instead get "Hello". The second parameter changes between length and position. 
</p>

<p><i>[08-2016, Chicago]</i></p>

<p>Fri PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>In 21.3.1 [basic.string] add the following constructor overload:</p>

<blockquote><pre>
[&hellip;]
basic_string(const basic_string&amp; str, size_type pos,
             const Allocator&amp; a = Allocator());
basic_string(const basic_string&amp; str, size_type pos, size_type n,
             const Allocator&amp; a = Allocator());
<ins>template&lt;class T&gt;
basic_string(const T&amp; t, size_type pos, size_type n, const Allocator&amp; a = Allocator());</ins>
explicit basic_string(basic_string_view&lt;charT, traits&gt; sv,
                      const Allocator&amp; a = Allocator());
[&hellip;]
</pre></blockquote>
</li>

<li><p>In 21.3.1.2 [string.cons] add the following ctor definition:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;
basic_string(const T&amp; t, size_type pos, size_type n, const Allocator&amp; a = Allocator());</ins>
</pre>
<blockquote>
<p>
<ins>-?- <i>Effects:</i> Creates a variable, <tt>sv</tt>, as if by <tt>basic_string_view&lt;charT, traits&gt; sv = t;</tt> 
and then behaves the same as:</ins>
<blockquote>
<pre>
<ins>basic_string(sv.substr(pos, n), a)</ins>
</pre>
</blockquote>
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution unless 
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2744" href="#2744">2744.</a> <tt>any</tt>'s <tt>in_place</tt> constructors</h3>
<p><b>Section:</b> 20.8.3.1 [any.cons] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2016-07-10 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#any.cons">active issues</a> in [any.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#any.cons">issues</a> in [any.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>in_place</tt> constructor that takes an <tt>initializer_list</tt> has both a <i>Requires:</i>
for <tt>is_constructible</tt> and a <i>Remarks:</i> for <tt>is_constructible</tt>. The one
that takes just a pack has just a <i>Requires:</i> for <tt>is_constructible</tt>.
<p/>
I think both of those should be <i>Remarks:</i>, i.e. SFINAEable constraints.
Otherwise querying is_constructible for an any with <tt>in_place_t</tt> will
not give a reasonable answer, and I utterly fail to see any implementation
burden in SFINAEing those constructors.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Modify 20.8.3.1 [any.cons] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any(ValueType&amp;&amp; value);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-7- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. If 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.
<p/>
-8- <i>Effects:</i> Constructs 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>.
<p/>
-9- <i>Remarks:</i> This constructor shall not participate in overload resolution if <tt>decay_t&lt;ValueType&gt;</tt> is the
same type as <tt>any</tt> <ins>or if <tt>ValueType</tt> is a specialization of <tt>in_place_type_t</tt></ins>.
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
template &lt;class T, class... Args&gt;
  explicit any(in_place_type_t&lt;T&gt;, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-11- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</del>
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution unless
<tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></ins>
<p/>
[&hellip;]
</p>
</blockquote>

<pre>
template &lt;class T, class U, class... Args&gt;
  explicit any(in_place_type_t&lt;T&gt;, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-15- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-19- <i>Remarks:</i> <del>The function</del><ins>This constructor</ins> shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2745" href="#2745">2745.</a> [fund.ts.v2] Implementability of LWG 2451</h3>
<p><b>Section:</b> 99 [fund.ts.v2::optional.object] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-07-10 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</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#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v2</b></p>
<p>
LWG <a href="lwg-defects.html#2451">2451</a> adds conditionally explicit converting constructors to <tt>optional&lt;T&gt;</tt> that accept:
</p>
<ol>
<li>Types convertible to <tt>T</tt>: <tt>template &lt;class U&gt; constexpr optional(T&amp;&amp;);</tt></li>
<li>Rvalue <tt>optional&lt;U&gt;</tt> when <tt>U&amp;&amp;</tt> is convertible to <tt>T</tt>: 
<tt>template &lt;class U&gt; constexpr optional(optional&lt;U&gt;&amp;&amp;);</tt></li>
<li>Lvalue <tt>const optional&lt;U&gt;</tt> when <tt>const U&amp;</tt> is convertible to <tt>T</tt>: 
<tt>template &lt;class U&gt; constexpr optional(const optional&lt;U&gt;&amp;);</tt></li>
</ol>
<p>
All three of these constructors are required to be <tt>constexpr</tt> "If <tt>T</tt>'s selected constructor is a 
<tt>constexpr</tt> constructor". While this is not problematic for #1, it is not possible in the current language 
to implement signatures #2 and #3 as <tt>constexpr</tt> functions for the same reasons that <tt>optional</tt>'s 
<em>non-converting</em> constructors from <tt>optional&lt;T&gt;&amp;&amp;</tt> and <tt>const optional&lt;T&gt;&amp;</tt> 
cannot be <tt>constexpr</tt>.
<p/>
We should remove the "<tt>constexpr</tt>" specifier from the declarations of the conditionally explicit converting 
constructors that accept <tt>optional&lt;U&gt;&amp;&amp;</tt> and <tt>const optional&lt;U&gt;&amp;</tt>, and strike 
the remarks requiring these constructors to be <tt>constexpr</tt>.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>
<p>This needs to be considered for C++17 as well</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/2016/n4600.html">N4600</a>.</p>

<blockquote class="note">
<p>
Wording relative to N4600 + LWG <a href="lwg-defects.html#2451">2451</a>, although it should be noted that this resolution should be applied 
wherever LWG <a href="lwg-defects.html#2451">2451</a> is applied, be that to the fundamentals TS or the specification of <tt>optional</tt> in the 
C++ Working Paper.
</p>
</blockquote>

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

<blockquote>
<pre>
template &lt;class T&gt;
class optional
{
public:
  typedef T value_type;

  // 5.3.1, Constructors
  [&hellip;]
  template &lt;class U&gt; constexpr optional(U&amp;&amp;);
  template &lt;class U&gt; <del>constexpr</del> optional(const optional&lt;U&gt;&amp;);
  template &lt;class U&gt; <del>constexpr</del> optional(optional&lt;U&lt;&amp;&amp;);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>In 99 [optional.object.ctor], modify the new signature specifications added by LWG <a href="lwg-defects.html#2451">2451</a></p>

<blockquote>
<pre>
template &lt;class U&gt;
  <del>constexpr</del> optional(const optional&lt;U&gt;&amp; rhs);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-48- <i>Remarks:</i> <del>If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor.</del> This constructor shall not participate in overload resolution 
unless [&hellip;]
</p>
</blockquote>
<pre>
template &lt;class U&gt;
  <del>constexpr</del> optional(optional&lt;U&gt;&amp;&amp; rhs);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-53- <i>Remarks:</i> <del>If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor.</del> This constructor shall not participate in overload resolution 
unless [&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2747" href="#2747">2747.</a> Possibly redundant <tt>std::move</tt> in [alg.foreach]</h3>
<p><b>Section:</b> 25.3.4 [alg.foreach] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-07-15 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#alg.foreach">issues</a> in [alg.foreach].</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.3.4 [alg.foreach] p3 says <i>Returns:</i> <tt>std::move(f)</tt>.
<p/>
12.8 [class.copy] says that since <tt>f</tt> is a function parameter overload resolution to select the constructor 
for the return value is first performed as if for an rvalue, so the <tt>std::move</tt> is redundant.
<p/>
It could be argued that it isn't entirely redundant, because it says that implementations can't do something slightly different like return an lvalue reference that is bound to <tt>f</tt>, which would prevent it being treated as an rvalue. We should discuss it.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Change 25.3.4 [alg.foreach] as indicated:</p>

<blockquote>
<pre>
template&lt;class InputIterator, class Function&gt;
  Function for_each(InputIterator first, InputIterator last, Function f);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-3- <i>Returns:</i> <tt><del>std::move(</del>f<del>)</del></tt>.
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2748" href="#2748">2748.</a> <tt>swappable</tt> traits for <tt>optional</tt>s</h3>
<p><b>Section:</b> 20.6.3.4 [optional.object.swap], 20.6.9 [optional.specalg] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2016-07-19 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>optional</tt> didn't benefit from the wording modifications by P0185 "Adding [<tt>nothrow_</tt>]<tt>swappable</tt> 
traits"; as such, it suffers from LWG <a href="lwg-defects.html#2456">2456</a>, and does not play nice with swappable traits.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Modify 20.6.3.4 [optional.object.swap] as indicated:</p>

<blockquote>
<pre>
void swap(optional&lt;T&gt;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-4- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:
</p>
<blockquote>
<pre>
is_nothrow_move_constructible_v&lt;T&gt; &amp;&amp; <ins>is_nothrow_swappable_v&lt;T&gt;</ins><del>noexcept(swap(declval&lt;T&amp;&gt;(), declval&lt;T&amp;&gt;()))</del>
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.6.9 [optional.specalg] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; void swap(optional&lt;T&gt;&amp; x, optional&lt;T&gt;&amp; y) noexcept(noexcept(x.swap(y)));
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Calls <tt>x.swap(y)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless 
<tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and <tt>is_swappable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2749" href="#2749">2749.</a> <tt>swappable</tt> traits for <tt>variant</tt>s</h3>
<p><b>Section:</b> 20.7.2.6 [variant.swap], 20.7.9 [variant.specalg] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Agust&iacute;n K-ballo Berg&eacute; <b>Opened:</b> 2016-07-19 <b>Last modified:</b> 2016-09-11</p>
<p><b>Priority: </b>1
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>variant</tt> does not play nice with swappable traits, the non-member specialized <tt>swap</tt> overload is not 
SFINAE friendly. On the other hand, the member <tt>swap</tt> is SFINAE friendly, albeit with an incomplete condition, 
when arguably it shouldn't be. Given the <i>Effects</i>, <i>Throws</i>, and <i>Remarks</i> clauses, the SFINAE 
condition should include <tt>is_move_constructible_v</tt> and <tt>is_move_assignable_v</tt> to account for the 
involvement of <tt>variant</tt>'s move constructor and move assignment operator (the <tt>noexcept</tt> specification is 
correct as is, since the move assignment operator would only be called for <tt>variant</tt>s with different alternatives). 
This SFINAE condition should apply to the non-member <tt>swap</tt> overload, while the member <tt>swap</tt> should require 
all alternatives are swappable (as defined by 17.6.3.2 [swappable.requirements]).
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P1 - review later in the week</p>
<p>Fri PM: Move to Tentatively Ready</p>

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

<ol>
<li><p>Modify 20.7.2.6 [variant.swap] as indicated:</p>

<blockquote>
<pre>
void swap(variant&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<ins>-?- <i>Requires:</i> Lvalues of type <tt>T<sub><i>i</i></sub></tt> shall be swappable and 
<tt>is_move_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp; is_move_assignable_v&lt;T<sub><i>i</i></sub>&gt;</tt> 
is <tt>true</tt> for all <tt><i>i</i></tt>.</ins>
<p/>
[&hellip;]
<p/>
-3- <i>Remarks:</i> <del>This function shall not participate in overload resolution unless <tt>is_swappable_v&lt;Ti&gt;</tt> 
is <tt>true</tt> for all <tt><i>i</i></tt>.</del> If an exception is thrown during the call to function 
<tt>swap(get&lt;<i>i</i>&gt;(*this), get&lt;<i>i</i>&gt;(rhs))</tt>, the states of the contained values of 
<tt>*this</tt> and of <tt>rhs</tt> are determined by the exception safety guarantee of swap for lvalues of 
<tt>T<sub><i>i</i></sub></tt> with <tt><i>i</i></tt> being <tt>index()</tt>. If an exception is thrown during the 
exchange of the values of <tt>*this</tt> and <tt>rhs</tt>, the states of the values of <tt>*this</tt> and of <tt>rhs</tt> 
are determined by the exception safety guarantee of <tt>variant</tt>'s move constructor and move assignment operator. 
The expression inside <tt>noexcept</tt> is equivalent to the logical AND of 
<tt>is_nothrow_move_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp; 
is_nothrow_swappable_v&lt;T<sub><i>i</i></sub>&gt;</tt> for all <tt><i>i</i></tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.7.9 [variant.specalg] as indicated:</p>

<blockquote>
<pre>
template &lt;class... Types&gt; void swap(variant&lt;Types...&gt;&amp; v, variant&lt;Types...&gt;&amp; w) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to <tt>v.swap(w)</tt>.
<p/>
-2- <i>Remarks:</i> <ins>This function shall not participate in overload resolution unless 
<tt>is_move_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp; is_move_assignable_v&lt;T<sub><i>i</i></sub>&gt; 
&amp;&amp; is_swappable_v&lt;T<sub><i>i</i></sub>&gt;</tt> is <tt>true</tt> for all <tt><i>i</i></tt>.</ins> The 
expression inside <tt>noexcept</tt> is equivalent to <tt>noexcept(v.swap(w))</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-13, Reopened by Casey Carter]</i></p>

<p>
It is possible to exchange the value of two variants using only move construction on the alternative types, as if by
<pre>
auto tmp = move(x);
x.emplace&lt;<i>i</i>&gt;(move(y));
y.emplace&lt;<i>j</i>&gt;(move(tmp));
</pre> 
where <i>i</i> is <tt>y.index()</tt> and <i>j</i> is <tt>tmp.index()</tt>. Consequently, <tt>variant</tt>'s member swap
need not require move assignable alternatives.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Move to Tentatively Ready</p>


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

<ol>
<li><p>Modify 20.7.2.6 [variant.swap] as indicated:</p>

<blockquote>
<pre>
void swap(variant&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p/>
<ins>-?- <i>Requires:</i> Lvalues of type <tt>T<sub><i>i</i></sub></tt> shall be swappable and 
<tt>is_move_constructible_v&lt;T<sub><i>i</i></sub>&gt;</tt> shall be <tt>true</tt> for all <tt><i>i</i></tt>.</ins>
<p/>
[&hellip;]
<p/>
-2- <i>Throws:</i> <ins>If <tt>index() == rhs.index()</tt>, a</ins><del>A</del>ny exception thrown by
<tt>swap(get&lt;<i>i</i>&gt;(*this), get&lt;<i>i</i>&gt;(rhs))</tt> with <i>i</i> being <tt>index()</tt><del> and
<tt>variant</tt>'s move constructor and assignment operator</del>. <ins>Otherwise, any exception thrown by the move
constructor of <tt>T<sub><i>i</i></sub></tt> or <tt>T<sub><i>j</i></sub></tt> with <tt><i>i</i></tt> being
<tt>index()</tt> and <tt><i>j</i></tt> being <tt>rhs.index()</tt>.</ins>
<p/>
-3- <i>Remarks:</i> <del>This function shall not participate in overload resolution unless <tt>is_swappable_v&lt;Ti&gt;</tt> 
is <tt>true</tt> for all <tt><i>i</i></tt>.</del> If an exception is thrown during the call to function
<tt>swap(get&lt;<i>i</i>&gt;(*this), get&lt;<i>i</i>&gt;(rhs))</tt>, the states of the contained values of
<tt>*this</tt> and of <tt>rhs</tt> are determined by the exception safety guarantee of swap for lvalues of
<tt>T<sub><i>i</i></sub></tt> with <tt><i>i</i></tt> being <tt>index()</tt>. If an exception is thrown during the 
exchange of the values of <tt>*this</tt> and <tt>rhs</tt>, the states of the values of <tt>*this</tt> and of <tt>rhs</tt> 
are determined by the exception safety guarantee of <tt>variant</tt>'s move constructor <del>and move assignment operator</del>. 
The expression inside <tt>noexcept</tt> is equivalent to the logical AND of 
<tt>is_nothrow_move_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp; 
is_nothrow_swappable_v&lt;T<sub><i>i</i></sub>&gt;</tt> for all <tt><i>i</i></tt>.
</blockquote>
</blockquote>
</li>

<li><p>Modify 20.7.9 [variant.specalg] as indicated:</p>

<blockquote>
<pre>
template &lt;class... Types&gt; void swap(variant&lt;Types...&gt;&amp; v, variant&lt;Types...&gt;&amp; w) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> Equivalent to <tt>v.swap(w)</tt>.
<p/>
-2- <i>Remarks:</i> <ins>This function shall not participate in overload resolution unless 
<tt>is_move_constructible_v&lt;T<sub><i>i</i></sub>&gt; &amp;&amp; is_swappable_v&lt;T<sub><i>i</i></sub>&gt;</tt> is
<tt>true</tt> for all <tt><i>i</i></tt>.</ins> The expression inside <tt>noexcept</tt> is equivalent to <tt>noexcept(v.swap(w))</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2750" href="#2750">2750.</a> [fund.ts.v2] LWG 2451 conversion constructor constraint</h3>
<p><b>Section:</b> 99 [fund.ts.v2::optional.object.ctor] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-07-20 <b>Last modified:</b> 2016-08-08</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><b>Addresses: fund.ts.v2</b></p>
<p>
LWG <a href="lwg-defects.html#2451">2451</a> adds a converting constructor to <tt>optional</tt> with signature:
</p>
<blockquote>
<pre>
template &lt;class U&gt;
constexpr optional(U&amp;&amp; v);
</pre>
</blockquote>
<p>
and specifies that "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>." 
This suffices to avoid this constructor being selected by overload resolution for arguments that should match the 
move constructor, but not for arguments that should match the copy constructor. The recent churn around tuple's 
constructors suggests that we want this constructor to not participate in overload resolution if 
<tt>remove_cv_t&lt;remove_reference_t&lt;U&gt;&gt;</tt> is the same type as <tt>T</tt>.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</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/2016/n4600.html">N4600</a>.</p>

<blockquote class="note">
<p>
Wording relative to N4600 + LWG <a href="lwg-defects.html#2451">2451</a>, although it should be noted that this resolution should be applied 
wherever LWG <a href="lwg-defects.html#2451">2451</a> is applied, be that to the fundamentals TS or the specification of <tt>optional</tt> in the 
C++ Working Paper.
</p>
</blockquote>

<ol>
<li><p>In 99 [optional.object.ctor], modify as indicated:</p>

<blockquote>
<pre>
template &lt;class U&gt;
  constexpr optional(U&amp;&amp; v);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-43- <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><ins>decay_t&lt;</ins>U<ins>&gt;</ins></tt> 
is not the same type as <tt>T</tt>. The constructor is explicit if and only if <tt>is_convertible_v&lt;U&amp;&amp;, T&gt;</tt> 
is <tt>false</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2752" href="#2752">2752.</a> &quot;Throws:&quot; clauses of <tt>async</tt> and <tt>packaged_task</tt> are unimplementable</h3>
<p><b>Section:</b> 30.6.8 [futures.async], 30.6.9.1 [futures.task.members] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2016-07-07 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>3
</p>
<p><b>View other</b> <a href="lwg-index-open.html#futures.async">active issues</a> in [futures.async].</p>
<p><b>View all other</b> <a href="lwg-index.html#futures.async">issues</a> in [futures.async].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>std::async</tt> is a request from the user for type erasure; as any given function gets passed to <tt>async</tt>
which returns only <tt>future&lt;ReturnType&gt;</tt>. Therefore, it needs to be able to allocate memory, as other issues
(e.g. LWG <a href="lwg-active.html#2202">2202</a>) indicate. However, async's <em>Throws</em> clause doesn't allow an implementation to do
this, as it permits only <tt>future_error</tt>.
<p/>
<tt>std::packaged_task</tt>'s constructor allocates memory using a user supplied allocator. An implementation needs to
call the user's <tt>allocate</tt> to allocate such memory. The user's allocate function is not constrained to throwing
only <tt>bad_alloc</tt>; it can raise whatever it wants, but <tt>packaged_task</tt>'s constructor prohibits this.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Alisdair thinks the third bullet is not quite right.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<ol>
<li><p>Change 30.6.8 [futures.async] p6 to:</p>

<blockquote>
<p>
<em>Throws:</em> <tt>system_error</tt> if <tt>policy == launch::async</tt> and the implementation is unable to start a
new thread<ins>, or <tt>std::bad_alloc</tt> if memory for the internal data structures could not be allocated</ins>.
</p>
</blockquote>
</li>
<li><p>Change 30.6.9.1 [futures.task.members] p5 to:</p>

<blockquote>
<pre>
template &lt;class F&gt;
  packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
  packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre>
<blockquote>
<p>
<em>Throws:</em>
</p>
<ol style="list-style-type: none">
<li>
<ins>(?) &mdash; A</ins><del>a</del>ny exceptions thrown by the copy or move constructor of <tt>f</tt><ins>.</ins><del>, or </del>
</li>
<li>
<ins>(?) &mdash; For the first version,</ins> <tt>std::bad_alloc</tt> if memory for the internal data structures
could not be allocated<ins>.</ins>
</li>
<li>
<ins>(?) &mdash; For the second version, any exceptions thrown by
<tt>std::allocator_traits&lt;Allocator&gt;::template rebind&lt;<em>unspecified</em>&gt;::allocate</tt></ins>.
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 30.6.8 [futures.async] p6 to:</p>

<blockquote>
<p>
<em>Throws:</em> <tt>system_error</tt> if <tt>policy == launch::async</tt> and the implementation is unable to start a
new thread<ins>, or <tt>std::bad_alloc</tt> if memory for the internal data structures could not be allocated</ins>.
</p>
</blockquote>
</li>
<li><p>Change 30.6.9.1 [futures.task.members] p5 to:</p>

<blockquote>
<pre>
template &lt;class F&gt;
  packaged_task(F&amp;&amp; f);
template &lt;class F, class Allocator&gt;
  packaged_task(allocator_arg_t, const Allocator&amp; a, F&amp;&amp; f);
</pre>
<blockquote>
<p>
<em>Throws:</em>
</p>
<ol style="list-style-type: none">
<li>
<ins>(?) &mdash; A</ins><del>a</del>ny exceptions thrown by the copy or move constructor of <tt>f</tt><ins>.</ins><del>, or </del>
</li>
<li>
<ins>(?) &mdash; For the first version,</ins> <tt>std::bad_alloc</tt> if memory for the internal data structures
could not be allocated<ins>.</ins>
</li>
<li>
<ins>(?) &mdash; For the second version, any exceptions thrown by
<tt>std::allocator_traits&lt;Allocator&gt;::template rebind_traits&lt;<em>unspecified</em>&gt;::allocate</tt></ins>.
</li>
</ol>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2753" href="#2753">2753.</a> Optional's constructors and assignments need constraints</h3>
<p><b>Section:</b> 20.6.3.1 [optional.object.ctor], 20.6.3.3 [optional.object.assign] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-07-22 <b>Last modified:</b> 2016-08-08</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>
To use <tt>optional&lt;T&gt;</tt> as if it were a <tt>T</tt> in generic contexts, <tt>optional&lt;T&gt;</tt>'s "generic" 
operations must behave as do those of <tt>T</tt> under overload resolution. At minimum, <tt>optional</tt>'s constructors 
and assignment operators should not participate in overload resolution with argument types that cannot be used to 
construct/assign the contained <tt>T</tt> so that <tt>is_constructible_v&lt;optional&lt;T&gt;, Args...&gt;</tt> 
(respectively <tt>is_assignable_v&lt;optional&lt;T&gt;&amp;, RHS&gt;</tt>) is equivalent to 
<tt>is_constructible_v&lt;T, Args...&gt;</tt> (respectively <tt>is_assignable_v&lt;T&amp;, RHS&gt;</tt>).
</p>
<p>
In passing, note that the Requires element for <tt>optional</tt>'s in-place <tt>initializer_list</tt> constructor 
unnecessarily duplicates its Remarks element; it should be removed.
</p>
<p>
It should also be noted that the resolution of LWG <a href="lwg-defects.html#2451">2451</a> adds constructors to <tt>optional</tt> with 
appropriate constraints, but does not constrain the additional assignment operators. If LWG chooses to apply the 
resolution of 2451 to the WP, the Requires elements of the additional assignment operators should also be converted 
to constraints as the wording herein does for the assignment operators in N4606.
</p>
<p><i>[2016-07 Chicago]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Remove 20.6.3.1 [optional.object.ctor] p3, and add a new paragraph after p6:</p>

<blockquote>
<pre>
optional(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
<ins>-?- <em>Remarks:</em> The function shall not participate in overload resolution unless 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.1 [optional.object.ctor] p7, and change p11 to:</p>

<blockquote>
<pre>
optional(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-7- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-11- <em>Remarks:</em> The expression inside <tt>noexcept</tt> is equivalent to 
<tt>is_nothrow_move_constructible_v&lt;T&gt;</tt>. <ins>The function shall not participate in 
overload resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.1 [optional.object.ctor] p12, and change p16 to:</p>

<blockquote>
<pre>
constexpr optional(const T&amp; v);
</pre>
<blockquote>
<p>
<del>-12- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-16- <em>Remarks:</em> If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, 
this constructor shall be a <tt>constexpr</tt> constructor. <ins>The function shall not participate 
in overload resolution unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.1 [optional.object.ctor] p17, and change p21 to:</p>

<blockquote>
<pre>
constexpr optional(T&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-17- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-21- <em>Remarks:</em> If <tt>T</tt>'s selected constructor is a <tt>constexpr</tt> constructor, this constructor shall 
be a <tt>constexpr</tt> constructor. <ins>The function shall not participate in overload resolution unless 
<tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.1 [optional.object.ctor] p22, and change p26 to:</p>

<blockquote>
<pre>
template &lt;class... Args&gt; 
  constexpr explicit optional(in_place_t, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-22- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-26- <em>Remarks:</em> If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, 
this constructor shall be a <tt>constexpr</tt> constructor. <ins>The function shall not participate in overload 
resolution unless <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.1 [optional.object.ctor] p27.</p>

<blockquote>
<pre>
template &lt;class U, class... Args&gt; 
  constexpr explicit optional(in_place_t, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is 
<tt>true</tt>.</del>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.3 [optional.object.assign] p4, and change p8 to:</p>

<blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-4- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_copy_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-8- <em>Remarks:</em> 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 copy constructor, no effect. If an exception is thrown 
during the call to <tt>T</tt>'s copy assignment, the state of its contained value is as defined by the exception 
safety guarantee of <tt>T</tt>'s copy assignment. <ins>The function shall not participate in overload resolution 
unless <tt>is_copy_constructible_v&lt;T&gt; &amp;&amp; is_copy_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.3 [optional.object.assign] p9, and add a new paragraph after p14:</p>

<blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-14- <i>Remarks:</i> [&hellip;] If an exception is thrown during the call to <tt>T</tt>'s move
assignment, the state of <tt>*val</tt> and <tt>*rhs.val</tt> is determined by the exception safety 
guarantee of <tt>T</tt>'s move assignment.
<p/>
<ins>The function shall not participate in overload resolution unless 
<tt>is_move_constructible_v&lt;T&gt; &amp;&amp; is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins></p>
</blockquote>
</blockquote>
</li>

<li><p>Remove 20.6.3.3 [optional.object.assign] p15, and change p19 to (yes, this wording is odd - the intent 
is that it will "do the right thing" after incorporation of LWG <a href="lwg-defects.html#2451">2451</a>):</p>

<blockquote>
<pre>
template &lt;class U&gt; optional&lt;T&gt;&amp; operator=(U&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-15- <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>.</del>
<p/>
[&hellip;]
<p/>
-19- <em>Remarks:</em> 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 <tt>is_same_v&lt;decay_t&lt;U&gt;, 
T&gt;<ins> &amp;&amp; is_constructible_v&lt;T, U&gt; &amp;&amp; is_assignable_v&lt;T&amp;, U&gt;</ins></tt> is 
<tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2754" href="#2754">2754.</a> The <tt>in_place</tt> constructors and <tt>emplace</tt> functions added by P0032R3 don't require <tt>CopyConstructible</tt></h3>
<p><b>Section:</b> 20.8.3.1 [any.cons], 20.8.3.2 [any.assign], 20.8.3.3 [any.modifiers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Ville Voutilainen <b>Opened:</b> 2016-07-05 <b>Last modified:</b> 2016-08-04</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#any.cons">active issues</a> in [any.cons].</p>
<p><b>View all other</b> <a href="lwg-index.html#any.cons">issues</a> in [any.cons].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The <tt>in_place</tt> constructors and <tt>emplace</tt> functions
added by <a href="http://wg21.link/p0032r3">P0032R3</a> don't require <tt>CopyConstructible</tt>.
<p/>
They must. Otherwise copying an <tt>any</tt> that's made to hold a non-<tt>CopyConstructible</tt>
type must fail with a run-time error. Since that's crazy, we want to prevent
storing non-<tt>CopyConstructible</tt> types in an <tt>any</tt>.
<p/>
Previously, the requirement for <tt>CopyConstructible</tt> was just on the converting
constructor template and the converting assignment operator template on <tt>any</tt>.
Now that we are adding two <tt>in_place</tt> constructor overloads and two
<tt>emplace</tt> overloads, it seems reasonable to require <tt>CopyConstructible</tt> in some more 
general location, in order to avoid repeating that requirement all over the place.
</p>

<p><i>[2016-07 &mdash; Chicago]</i></p>

<p>Monday: P1</p>
<p>Tuesday: Ville/Billy/Billy provide wording</p>

<p><i>[2016-08-02: Daniel comments]</i></p>

<p>
The P/R wording of this issue brought to my intention that the recently added <tt>emplace</tt> functions
of <tt>std::any</tt> introduced a breakage of a previous class invariant that only a <tt>decay</tt>ed type could
be stored as object into an <tt>any</tt>, this prevented storing arrays, references, functions, and <i>cv</i>-qualified
types. The new constraints added my Ville do prevent some of these types (e.g. neither arrays nor functions meet
the <tt>CopyConstructible</tt> requirements), but we need to cope with <i>cv</i>-qualified types and reference types.
</p>

<p><i>[2016-08-02: Agust&iacute;n K-ballo Berg&eacute; comments]</i></p>

<p>
Presumably the constructors <tt>any(in_place_type_t&lt;T&gt;, ...)</tt> would need to be modified in the same way 
the <tt>emplace</tt> overloads were.
</p>

<p><i>[2016-08-02: Ville adjusts the P/R to cope with the problems pointed out by Daniel's and Agust&iacute;n's comments]</i></p>

<p>Ville notes that <a href="lwg-active.html#2746">2746</a>, <a href="lwg-active.html#2754">2754</a> and <a href="lwg-active.html#2756">2756</a> all go together.</p>

<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to N4606.
</p>
<blockquote class="note">
<p>
Drafting note: this P/R doesn't turn the <i>Requires</i>-clauses into <i>Remarks</i>-clauses.
We might want to do that separately, because SFINAEing the constructors
allows users to query for <tt>is_constructible</tt> and get the right answer. Failing
to mandate the SFINAE will lead to non-portable answers for <tt>is_constructible</tt>.
Currently, libstdc++ SFINAEs. That should be done as a separate issue,
as this issue is an urgent bug-fix but the mandated SFINAE is not.
</p>
</blockquote>

<ol>
<li><p>Change 20.8.3 [any.class], class <tt>any</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
class any {
public:
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt;, Args&amp;&amp;...);
    
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    void emplace(Args&amp;&amp; ...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    void emplace(initializer_list&lt;U&gt;, Args&amp;&amp;...);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.8.3.1 [any.cons] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any(ValueType&amp;&amp; value);
</pre>
<blockquote>
<p>
-6- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
-7- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. 
<del>If <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> This constructor shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt>decay_t&lt;ValueType&gt;</tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>remove_cv_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-11- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements</ins>
<del><tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution
unless <tt>is_reference_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_array_v&lt;T&gt;</tt> is <tt>false</tt>,
<tt>is_function_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>remove_cv_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-15- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements</ins>
<del><tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-19- <i>Remarks:</i> The function shall not participate in overload resolution unless 
<ins><tt>is_reference_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_array_v&lt;T&gt;</tt> is <tt>false</tt>,
<tt>is_function_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and</ins> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.2 [any.assign] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any&amp; operator=(ValueType&amp;&amp; rhs);
</pre>
<blockquote>
<p>
-7- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
-8- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. <del>If 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> This operator shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt>decay_t&lt;ValueType&gt;</tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.3 [any.modifiers] as indicated:</p>

<blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  void emplace(Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>remove_cv_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-1- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements</ins>
<del><tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-5- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does not 
contain a value, and any previously contained object has been destroyed. <ins>This function shall not participate 
in overload resolution unless <tt>is_reference_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_array_v&lt;T&gt;</tt> is 
<tt>false</tt>, <tt>is_function_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_copy_constructible_v&lt;T&gt;</tt> is 
<tt>true</tt> and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>

<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  void emplace(initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>remove_cv_t&lt;ValueType&gt;</tt>.</ins>
<p/>
<ins>-?- <i>Requires</i>: <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements.</ins>
<p/>
-6- <i>Effects:</i> [&hellip;]
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does 
not contain a value, and any previously contained object has been destroyed. The function shall not participate in overload
resolution unless <ins><tt>is_reference_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_array_v&lt;T&gt;</tt> is <tt>false</tt>,
<tt>is_function_v&lt;T&gt;</tt> is <tt>false</tt>, <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and</ins> 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-03: Ville comments and revises his proposed wording]</i></p>

<p>
After discussing the latest P/R, here's an update. What this update does is that:
</p>
<ol>
<li><p>It strikes the <i>Requires</i>-clauses and does <em>not</em> add
<tt>CopyConstructible</tt> to the <i>Requires</i>-clauses.
<p/>
Rationale: <tt>any</tt> doesn't care whether the type it holds satisfies the
semantic requirements of the <tt>CopyConstructible</tt> concept. The syntactic 
requirements are now SFINAE constraints in <i>Requires</i>-clauses.</p></li>
<li><p>It reverts back towards <tt>decay_t</tt> rather than <tt>remove_cv_t</tt>, and does
<em>not</em> add the suggested SFINAE constraints for <tt>is_reference</tt>/<tt>is_array</tt>/<tt>is_function</tt>.
<p/>
Rationale:
</p>
<ol style="list-style-type:lower-alpha">
<li><p><tt>any</tt> decays by design. It's to some extent inconsistent
to not protect against decay in the <tt>ValueType</tt> constructor/assignment operator, but to protect
against decay in the <tt>in_place_t</tt> constructors and <tt>emplace</tt> functions</p></li>
<li><p>I think it's saner to just decay than to potentially run into
situations where I need to <tt>remove_reference</tt> inside <tt>in_place_t</tt>.</p></li>
</ol>
</li>
</ol>
<p>
Based on that, this P/R should supersede the previous one. We want to
look at this new P/R in LWG and potentially send it to LEWG for verification. 
Personally, I think this P/R is the more conservative one, doesn't add 
significant new functionality, and is consistent, and is
thus not really Library-Evolutionary.
</p>

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

<ol>
<li><p>Change 20.8.3 [any.class], class <tt>any</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
class any {
public:
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt;, Args&amp;&amp;...);
    
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    void emplace(Args&amp;&amp; ...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    void emplace(initializer_list&lt;U&gt;, Args&amp;&amp;...);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.8.3.1 [any.cons] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any(ValueType&amp;&amp; value);
</pre>
<blockquote>
<p>
-6- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
<del>-7- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. 
If <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> This constructor shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt>decay_t&lt;ValueType&gt;</tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
<del>-11- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution
unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
<del>-15- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-19- <i>Remarks:</i> The function shall not participate in overload resolution unless 
<ins><tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and</ins> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.2 [any.assign] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any&amp; operator=(ValueType&amp;&amp; rhs);
</pre>
<blockquote>
<p>
-7- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
<del>-8- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. If 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> This operator shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt>decay_t&lt;ValueType&gt;</tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.3 [any.modifiers] as indicated:</p>

<blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  void emplace(Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
<del>-1- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-5- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does not 
contain a value, and any previously contained object has been destroyed. <ins>This function shall not participate 
in overload resolution unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is 
<tt>true</tt> and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>

<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  void emplace(initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be equal to <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-6- <i>Effects:</i> [&hellip;]
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does 
not contain a value, and any previously contained object has been destroyed. The function shall not participate in overload
resolution unless <ins><tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and</ins> 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2016-08-03: Ville comments and revises his proposed wording]</i></p>

<p>
This P/R brings back the <tt>CopyConstructible</tt> parts of the relevant
Requires-clauses but removes the other parts of the Requires-clauses.
</p>
<p><i>[2016-08 - Chicago]</i></p>

<p>Thurs PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Change 20.8.3 [any.class], class <tt>any</tt> synopsis, as indicated:</p>

<blockquote>
<pre>
class any {
public:
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt;, Args&amp;&amp;...);
    
  [&hellip;]
  template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
    void emplace(Args&amp;&amp; ...);
  template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
    void emplace(initializer_list&lt;U&gt;, Args&amp;&amp;...);
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Change 20.8.3.1 [any.cons] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any(ValueType&amp;&amp; value);
</pre>
<blockquote>
<p>
-6- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
-7- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. 
<del>If <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> This constructor shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt><ins>T</ins><del>decay_t&lt;ValueType&gt;</del></tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-11- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> 
requirements</ins><del><tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall not participate in overload resolution
unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  explicit any(in_place_type_t&lt;<del>T</del><ins>ValueType</ins>&gt;, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-15- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> 
requirements</ins><del><tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-19- <i>Remarks:</i> The function shall not participate in overload resolution unless 
<ins><tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> 
and</ins> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.2 [any.assign] as indicated:</p>

<blockquote>
<pre>
template&lt;class ValueType&gt;
  any&amp; operator=(ValueType&amp;&amp; rhs);
</pre>
<blockquote>
<p>
-7- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.
<p/>
-8- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements. <del>If 
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>false</tt>, the program is ill-formed.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> This operator shall not participate in overload resolution <del>if</del><ins>unless</ins> 
<tt><ins>T</ins><del>decay_t&lt;ValueType&gt;</del></tt> is <ins>not</ins> the same type as <tt>any</tt> <ins>and
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt></ins>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>Change 20.8.3.3 [any.modifiers] as indicated:</p>

<blockquote>
<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class... Args&gt;
  void emplace(Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
-1- <i>Requires:</i> <ins><tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> 
requirements</ins><del><tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt></del>.
<p/>
[&hellip;]
<p/>
-5- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does not 
contain a value, and any previously contained object has been destroyed. <ins>This function shall not participate 
in overload resolution unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is 
<tt>true</tt> and <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>

<pre>
template &lt;class <del>T</del><ins>ValueType</ins>, class U, class... Args&gt;
  void emplace(initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<ins>-?- Let <tt>T</tt> be <tt>decay_t&lt;ValueType&gt;</tt>.</ins>
<p/>
<ins>-?- <i>Requires:</i> <tt>T</tt> shall satisfy the <tt>CopyConstructible</tt> requirements.</ins>
<p/>
-6- <i>Effects:</i> [&hellip;]
<p/>
[&hellip;]
<p/>
-9- <i>Remarks:</i> If an exception is thrown during the call to <tt>T</tt>'s constructor, <tt>*this</tt> does 
not contain a value, and any previously contained object has been destroyed. The function shall not participate in overload
resolution unless <ins><tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and</ins> 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args...&gt;</tt> is <tt>true</tt>.
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2755" href="#2755">2755.</a> &sect;[string.view.io] uses non-existent <tt>basic_string_view::to_string</tt> function</h3>
<p><b>Section:</b> 21.4.4 [string.view.io], 21.3.2.9 [string.io] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Baker <b>Opened:</b> 2016-07-26 <b>Last modified:</b> 2016-08-08</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 looking at N4606, [string.view.io] has an <i>Effects</i> clause that references <tt>basic_string_view::to_string</tt> 
which no longer exists after the application of <a href="http://wg21.link/p0254r2">P0254R2</a>.
</p>

<p><i>[2016-07-26, Marshall suggests concrete wording]</i></p>

<p><i>[2016-07 Chicago LWG]</i></p>

<p>Monday: P0 - tentatively ready</p>


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

<ol>
<li><p>Modify 21.3.2.9 [string.io] as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits, class Allocator&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
               const basic_string&lt;charT, traits, Allocator&gt;&amp; str);
</pre>
<blockquote>
<p>
-5- <i>Effects:</i> <ins>Equivalent to: <tt>return os &lt;&lt; basic_string_view&lt;charT, 
traits&gt;(str);</tt></ins><del>Behaves as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) 
of <tt>os</tt>. Forms a character sequence <tt>seq</tt>, initially consisting of the elements defined by the 
range <tt>[str.begin(), str.end())</tt>. Determines padding for <tt>seq</tt> as described in 
27.7.3.6.1 [ostream.formatted.reqmts]. Then inserts <tt>seq</tt> as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, 
where <tt>n</tt> is the larger of <tt>os.width()</tt> and <tt>str.size()</tt>; then calls <tt>os.width(0)</tt>.</del>
<p/>
<del>-6- <i>Returns:</i> <tt>os</tt></del>
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 21.4.4 [string.view.io] as indicated:</p>

<blockquote>
<pre>
template&lt;class charT, class traits&gt;
  basic_ostream&lt;charT, traits&gt;&amp;
    operator&lt;&lt;(basic_ostream&lt;charT, traits&gt;&amp; os,
               basic_string_view&lt;charT, traits&gt; str);
</pre>
<blockquote>
<p>
-1- <i>Effects:</i> <del>Equivalent to: <tt>return os &lt;&lt; str.to_string();</tt></del><ins>Behaves 
as a formatted output function (27.7.3.6.1 [ostream.formatted.reqmts]) of <tt>os</tt>. Forms a character 
sequence <tt>seq</tt>, initially consisting of the elements defined by the range <tt>[str.begin(), 
str.end())</tt>. Determines padding for <tt>seq</tt> as described in 27.7.3.6.1 [ostream.formatted.reqmts]. Then 
inserts <tt>seq</tt> as if by calling <tt>os.rdbuf()-&gt;sputn(seq, n)</tt>, where <tt>n</tt> is the larger of 
<tt>os.width()</tt> and <tt>str.size()</tt>; then calls <tt>os.width(0)</tt>.</ins>
<p/>
<ins>-?- <i>Returns:</i> <tt>os</tt></ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2756" href="#2756">2756.</a> C++ WP <tt>optional&lt;T&gt;</tt> should 'forward' <tt>T</tt>'s implicit conversions</h3>
<p><b>Section:</b> 20.6.3 [optional.object] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-07-26 <b>Last modified:</b> 2016-10-07</p>
<p><b>Priority: </b>1
</p>
<p><b>View other</b> <a href="lwg-index-open.html#optional.object">active issues</a> in [optional.object].</p>
<p><b>View all other</b> <a href="lwg-index.html#optional.object">issues</a> in [optional.object].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2451">2451</a> adds converting constructors and assignment operators to <tt>optional</tt>. The committee 
voted to apply it to the Library Fundamentals 2 TS WP in Oulu as part of LWG Motion 3. In both LWG and LEWG 
discussion of this issue, it was considered to be critical to apply to the specification of <tt>optional</tt> 
before shipping C++17 &mdash; it was an oversight on the part of LWG that there was no motion brought to apply 
this resolution to the C++ WP.
<p/>
LWG <a href="lwg-active.html#2745">2745</a> proposes removal of the <tt>constexpr</tt> specifier from the declarations of the 
converting constructors from <tt>const optional&lt;U&gt;&amp;</tt> and <tt>optional&lt;U&gt;&amp;&amp;</tt> 
since they are not implementable as <tt>constexpr</tt> constructors in C++17.
<p/>
This issue proposes application of the resolution of LWG <a href="lwg-defects.html#2451">2451</a> as amended by LWG <a href="lwg-active.html#2745">2745</a> 
to the specification of <tt>optional</tt> in the C++ WP.
</p>

<p><i>[2016-07 &mdash; Chicago]</i></p>

<p>Monday: Priority set to 1; will re-review later in the week</p>

<p><i>[2016-08-03, Tomasz comments]</i></p>

<ol>
<li><p>Value forwarding constructor (<tt>template&lt;typename U&gt; optional(U&amp;&amp;)</tt>) is underspecified.</p>
<p>For the following use code:</p>

<blockquote><pre>
optional&lt;T&gt; o1;
optional&lt;T&gt; o2(o1);
</pre></blockquote>

<p>
The second constructor will invoke value forwarding <tt>(U = optional&lt;T&gt;&amp;)</tt> constructor (better match) 
instead of the <tt>optional&lt;T&gt;</tt> copy constructor, in case if <tt>T</tt> can be constructed from 
<tt>optional&lt;T&gt;</tt>. This happens for any type <tt>T</tt> that has unconstrained perfect forwarding constructor, 
especially <tt>optional&lt;any&gt;</tt>.
</p>
</li>
<li>
<p>The behavior of the construction of the <tt>optional&lt;T&gt; ot</tt> from <tt>optional&lt;U&gt; ou</tt> is 
inconsistent for classes <tt>T</tt> than can be constructed both from <tt>optional&lt;U&gt;</tt> and <tt>U</tt>. 
There are two possible semantics for such operation:
</p>
<ul>
<li><p><em>unwrapping:</em> if <tt>ou</tt> is initialized (<tt>bool(ou)</tt>), initialize contained value of <tt>ot</tt> 
from <tt>*ou</tt>, otherwise make <tt>ot</tt> uninitialized (<tt>!bool(ot)</tt>)</p></li>
<li><p><em>value forwarding:</em> initialize contained value of <tt>ot</tt> from <tt>ou</tt>, <tt>ot</tt> is always 
initialized (<tt>bool(ot)</tt>). 
<p/>
With the proposed resolution, construction is preferring <em>value forwarding</em>, 
while assignment is always using <em>unwrapping</em>.</p></li>
</ul>
<p>
For example, if we consider following class:
</p>
<blockquote>
<pre>
struct Widget
{
  Widget(int);
  Widget(optional&lt;int&gt;);
};
</pre>
</blockquote>
<p>
Notice, that such set of constructor is pretty common in situation when the construction of the 
<tt>Widget</tt> from known value is common and usage of <tt>optional</tt> version is rare. In such situation, 
presence of <tt>Widget(int)</tt> construction is an optimization used to avoid unnecessary empty checks and 
construction <tt>optional&lt;int&gt;</tt>.
<p/>
For the following declarations:
</p>
<blockquote>
<pre>
optional&lt;Widget&gt; w1(make_optional(10));
optional&lt;Widget&gt; w2;
w2 = make_optional(10);
</pre>
</blockquote>
<p>
The <tt>w1</tt> will contain a value created using <tt>Widget(optional&lt;int&gt;)</tt> constructor, 
as corresponding <em>unwrapping</em> constructor (<tt>optional&lt;U&gt; const&amp;</tt>) is eliminated by 
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> 
(<tt>is_constructible_v&lt;Widget, const optional&lt;int&gt;&amp;&gt;</tt>) having a <tt>true</tt> value.
In contrast <tt>w2</tt> will contain a value created using <tt>Widget(int)</tt> constructor, as corresponding 
value forwarding assignment (<tt>U&amp;&amp;</tt>) is eliminated by the fact that 
<tt>std::decay_t&lt;U&gt;</tt> (<tt>optional&lt;int&gt;</tt>) is specialization of <tt>optional</tt>.
<p/>
In addition, the construction is having a preference for <em>value forwarding</em> and assignment is always using 
<em>unwrapping</em>. That means that for the following class:
</p>
<blockquote><pre>
struct Thingy
{
   Thingy(optional&lt;string&gt;);
};

optional&lt;Thingy&gt; t1(optional&lt;string&gt;("test"));
</pre></blockquote>
<p>
The <tt>t1</tt> has a contained value constructed from using <tt>Thingy(optional&lt;std::string&gt;)</tt>, 
as unwrapping constructor (<tt>optional&lt;U&gt; const&amp;</tt>) are eliminated by the 
<tt>is_constructible&lt;T, U const&amp;&gt;</tt> (<tt>is_constructible&lt;Thingy, std::string const&amp;&gt;</tt>) 
being <tt>false</tt>. However the following:
</p>
<blockquote><pre>
t1 = optional&lt;std::string&gt;("test2");
</pre></blockquote>
<p>
will not compile, because, the <em>value forwarding</em> assignment (<tt>U&amp;&amp;</tt>) is eliminated by 
<tt>std::decay_t&lt;U&gt;</tt> (<tt>optional&lt;std::string&gt;</tt>) being optional specialization and the 
<em>unwrapping</em> assignment (<tt>optional&lt;U&gt; const&amp;</tt>) is ill-formed because 
<tt>is_constructible&lt;T, U const&amp;&gt;</tt> (<tt>is_constructible&lt;Thingy, std::string const&amp;&gt;</tt>) 
is <tt>false</tt>.
</p>
</li>
<li>
<p>
The semantics of construction and assignment, of <tt>optional&lt;optional&lt;V&gt;&gt;</tt> from 
<tt>optional&lt;U&gt;</tt> where <tt>U</tt> is convertible to/ same as <tt>T</tt> is also inconsistent. Firstly, 
in this situation the <tt>optional&lt;V&gt;</tt> is a type that can be constructed both from 
<tt>optional&lt;U&gt;</tt> and <tt>U</tt> so it fails into set of problem described above. However in 
addition we have following non-template constructor in <tt>optional&lt;T&gt;</tt>:
</p>
<blockquote><pre>
optional(T const&amp;);
</pre></blockquote>
<p>
Which for <tt>optional&lt;optional&lt;V&gt;&gt;</tt> is equivalent to:
</p>
<blockquote><pre>
optional(optional&lt;V&gt; const&amp;);
</pre></blockquote>
<p>
While there is no corresponding non-template assignment from <tt>T const&amp;</tt>, to make sure that 
<tt>o = {};</tt> always clear an <tt>optional o</tt>.
<p/>
So for the following declarations:
</p>
<blockquote><pre>
optional&lt;int&gt; oi;
optional&lt;short&gt; os;

optional&lt;optional&lt;int&gt;&gt; ooi1(oi);
optional&lt;optional&lt;int&gt;&gt; ooi2(os);
</pre></blockquote>
<p>
The <tt>ooi1</tt> uses <em>from-<tt>T</tt></em> constructor, while <tt>ooi2</tt> uses <em>value forwarding</em> constructor. 
In this case both <tt>ooi1</tt> and <tt>ooi2</tt> are initialized and their contained values <tt>*ooi1</tt>, 
<tt>*ooi2</tt> are uninitialized <tt>optional</tt>s. However, if we will attempt to make construction consistent 
with assignment, by preferring <em>unwrapping</em> (<tt>optional&lt;U&gt; const&amp;</tt>), then <tt>ooi2</tt> 
will end up being uninitialized.
<p/>
In summary, I believe that relation between <em>unwrapping</em>, <em>value forwarding</em> and 
<em>from-<tt>T</tt></em> construction/assignment is to subtle to being handled as defect report and requires 
a full paper analyzing possible design and their pros/cons.
</p>
</li>
</ol>

<p>Tuesday PM: Ville and Eric to implement and report back in Issaquah. Moved to Open</p>
<p>Ville notes that <a href="lwg-active.html#2746">2746</a>, <a href="lwg-active.html#2754">2754</a> and <a href="lwg-active.html#2756">2756</a> all go together.</p>

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

<ol>
<li><p>Modify 20.6.3 [optional.object] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; class optional
{
public:
  using value_type = T;
  
  <i>// 20.6.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; optional(const optional&lt;U&gt; &amp;);
  template &lt;class U&gt; optional(optional&lt;U&gt; &amp;&amp;);</ins>
  
  [&hellip;]
  
  <i>// 20.6.3.3, Assignment</i>
  optional &amp;operator=(nullopt_t) noexcept;
  optional &amp;operator=(const optional &amp;);
  optional &amp;operator=(optional &amp;&amp;) noexcept(<i>see below</i>);
  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 20.6.3.1 [optional.object.ctor], insert new signature specifications after p31:</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;
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>: 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;
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>: 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 20.6.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>
</blockquote>

<p><i>[2016-08-05 Chicago LWG]</i></p>

<p>
Ville provides revised wording, that also fixes LWG <a href="lwg-active.html#2753">2753</a>.
<p/>
Rationale:
</p>
<ol>
<li><p>The resolution of LWG <a href="lwg-active.html#2753">2753</a> makes special
member functions defined as deleted in case the desired
constraints aren't met.</p></li>
<li><p>There is no decay for the converting
constructor <tt>optional(U&amp;&amp;)</tt>, there is a <tt>remove_reference</tt> instead.
The target type may hold a <i>cv</i>-qualified type, and the incoming
type may hold a <i>cv</i>-qualified type, but neither can hold a reference.
Thus, <tt>remove_reference</tt> is what we need, <tt>remove_cv</tt> would
be wrong, and <tt>decay</tt> would be wrong.</p></li>
<li><p>There is no <tt>decay</tt> or <tt>remove_reference</tt> for converting constructors like
<tt>optional(optional&lt;U&gt;)</tt>, because none is needed.</p></li>
<li><p>For <tt>optional(U&amp;&amp;)</tt>, an added constraint is that <tt>U</tt> is
not a specialization of <tt>optional</tt></p></li>
</ol>

<p><i>[2016-08, Chicago]</i></p>

<p>Fri PM: Move to Tentatively Ready</p>

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

<ol>
<li><p>Modify 20.6.3 [optional.object] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; class optional
{
public:
  using value_type = T;
  
  <i>// 20.6.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; <em>EXPLICIT</em> constexpr optional(U &amp;&amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(const optional&lt;U&gt; &amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(optional&lt;U&gt; &amp;&amp;);</ins>
  
  [&hellip;]
  
  <i>// 20.6.3.3, Assignment</i>
  optional &amp;operator=(nullopt_t) noexcept;
  optional &amp;operator=(const optional &amp;);
  optional &amp;operator=(optional &amp;&amp;) noexcept(<i>see below</i>);
  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>Change 20.6.3.1 [optional.object.ctor] as indicated:</p>

<blockquote>
<pre>
optional(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall be defined as deleted
unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-7- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to <tt>is_nothrow_move_constructible_v&lt;T&gt;</tt>.
<ins>This constructor shall be defined as deleted unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
constexpr optional(const T&amp; v);
</pre>
<blockquote>
<p>
<del>-12- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-16- <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. <ins>This constructor shall not participate in overload
resolution unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
constexpr optional(T&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-17- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-21- <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. <ins>This constructor shall not participate in overload
resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class... Args&gt; constexpr explicit optional(in_place_t, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-22- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-26- <i>Remarks:</i> If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, 
this constructor shall be a <tt>constexpr</tt> constructor. <ins>This constructor shall not participate in overload
resolution unless <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U, class... Args&gt;
  constexpr explicit optional(in_place_t, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is 
<tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-31- <i>Remarks:</i> The <del>function</del><ins>constructor</ins> shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>. 
If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor.
</p>
</blockquote>
<p>
<ins>[<i>Note:</i> The following constructors are conditionally specified
as explicit. 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;
  <em>EXPLICIT</em> 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>, <tt>remove_reference_t&lt;U&gt;</tt> 
is not the same type as <tt>T</tt>, and <tt>U</tt> is not a specialization of <tt>optional</tt>. The
constructor is explicit 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;
  <em>EXPLICIT</em> 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> This constructor shall not participate in
overload resolution unless <tt>is_constructible_v&lt;T, const U&amp;&gt;</tt> is 
<tt>true</tt> and <tt>is_same_v&lt;U, T&gt;</tt> is <tt>false</tt>. The constructor is 
explicit 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;
  <em>EXPLICIT</em> 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> 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>is_same_v&lt;U, T&gt;</tt> is <tt>false</tt>. The constructor is 
explicit 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>Change 20.6.3.3 [optional.object.assign] as indicated:</p>

<blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-4- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_copy_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-8- <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 copy constructor, no effect. If an exception is thrown
during the call to <tt>T</tt>'s copy assignment, the state of its contained value is as defined by the exception
safety guarantee of <tt>T</tt>'s copy assignment. <ins>This operator shall be defined as deleted unless
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and <tt>is_copy_assignable_v&lt;T&gt;</tt> is
<tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-13- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:
</p>
<blockquote><pre>
is_nothrow_move_assignable_v&lt;T&gt; &amp;&amp; is_nothrow_move_constructible_v&lt;T&gt;
</pre></blockquote>
<p>
-14- 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 move constructor, the state of <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move constructor. If an exception is 
thrown during the call to <tt>T</tt>'s move assignment, the state of <tt>*val</tt> and <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move assignment. <ins>This operator 
shall be defined as deleted unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U&gt; optional&lt;T&gt;&amp; operator=(U&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-15- <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>.</del>
<p/>
[&hellip;]
<p/>
-19- <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. <del>The</del><ins>This</ins> function
shall not participate in overload resolution unless <del><tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt></del> 
<ins><tt>decay_t&lt;U&gt;</tt> is not <tt>nullopt_t</tt>, <tt>decay_t&lt;U&gt;</tt> is not a specialization of 
<tt>optional</tt>, <tt>is_constructible_v&lt;T, U&gt;</tt> is <tt>true</tt> and <tt>is_assignable_v&lt;T&amp;, 
U&gt;</tt></ins> is <tt>true</tt>.
<p/>
<del>-20- <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>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_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> and <tt>is_same_v&lt;U, 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>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_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> and <tt>is_same_v&lt;U, T&gt;</tt> is 
<tt>false</tt>.</ins>
</p>
</blockquote>

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

<p><i>[2016-08-08 Ville reopens and provides improved wording]</i></p>

<p>
This alternative proposed wording also resolves <a href="lwg-active.html#2753">2753</a>.
<p/>
The constructors that take a const <code>T&amp;</code> or <code>T&amp;&amp;</code> are replaced by 
a constructor template that takes a <code>U&amp;&amp;</code> and defaults <code>U = T</code>. This 
allows copy-list-initialization with empty braces to still work:
</p>
<blockquote><pre>
optional&lt;<em>whatever</em>&gt; o = {}; <i>// equivalent to initializing <code>optional</code> with <code>nullopt</code></i>
</pre></blockquote>
<p>
This resolution makes converting constructors and assignments have the same capabilities, including 
using arguments that can't be deduced. That is achieved by using a perfect-forwarding constructor
and an assignment operator that default their argument to <code>T</code>. We don't need separate 
overloads for <code>T</code>, the overload for <code>U</code> does the job:
</p>
<blockquote><pre>
optional&lt;vector&lt;int&gt;&gt; ovi{{1, 2, 3}}; // still works
ovi = {4, 5, 6, 7}; // now works, didn't work before
</pre></blockquote>
<p>
Furthermore, this proposed wording makes <code>optional</code> "always unwrap". That is, the result 
of the following initializations is the same:
</p>
<blockquote><pre>
optional&lt;optional&lt;int&gt;&gt; oi = optional&lt;int&gt;();
optional&lt;optional&lt;int&gt;&gt; oi = optional&lt;short&gt;();
</pre></blockquote>
<p>
Both of those initializations initialize the <code>optional</code> wrapping
another <code>optional</code> as if initializing with <code>nullopt</code>. Assignments
do the same. These changes solve the issues pointed out by Tomasz Kami&nacute;ski.
<p/>
This P/R has been implemented and tested as a modification on top of libstdc++'s <code>optional</code>.
</p>

<p><i>[2016-08-08 Ville and Tomasz collaborate and improve wording]</i></p>

<p>
The suggested wording retains <tt>optional</tt>'s converting constructors and assignment
operators, but provides sane results for the types Tomasz Kaminski depicts
in previous discussions.
<p/>
As opposed to the current P/R of this issue, which does "always unwrap",
this P/R does "always value-forward unless the incoming type is exactly
a type that a special member function takes by reference, and don't
unwrap if a value-forwarder can take an optional by any kind of reference".
<p/>
I and Tomasz believe this is the best compromise between the different
desires, and thus the best outcome so far.
<p/>
This P/R has been implemented and tested on libstdc++.
</p>

<p><i>[2016-09-08 Casey Carter finetunes existing resolution for move members]</i></p>


<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Move to Tentatively Ready</p>

<p><i>[2016-10-06 Ville Voutilainen finetunes the resolution for assignment from scalars]</i></p>


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

<ol>
<li><p>Modify 20.6.3 [optional.object] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; class optional
{
public:
  using value_type = T;
  
  <i>// 20.6.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>);
  <del>constexpr optional(const T &amp;);</del>
  <del>constexpr optional(T &amp;&amp;);</del>
  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 = T&gt; <em>EXPLICIT</em> constexpr optional(U &amp;&amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(const optional&lt;U&gt; &amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(optional&lt;U&gt; &amp;&amp;);</ins>
  
  [&hellip;]
  
  <i>// 20.6.3.3, Assignment</i>
  optional &amp;operator=(nullopt_t) noexcept;
  optional &amp;operator=(const optional &amp;);
  optional &amp;operator=(optional &amp;&amp;) noexcept(<i>see below</i>);
  template &lt;class U <ins>= T</ins>&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>Change 20.6.3.1 [optional.object.ctor] as indicated:</p>

<blockquote>
<pre>
optional(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall be defined as deleted
unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-7- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to <tt>is_nothrow_move_constructible_v&lt;T&gt;</tt>.
<ins>This constructor shall not participate in overload resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
<del>constexpr optional(const T&amp; v);</del>
</pre>
<blockquote>
<p>
<del>-12- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
<del>-13- <i>Effects:</i> Initializes the contained value as if direct-non-list-initializing an object of type <code>T</code> 
with the expression <code>v</code>.</del>
<p/>
<del>-14- <i>Postcondition:</i> <code>*this</code> contains a value.</del>
<p/>
<del>-15- <i>Throws:</i> Any exception thrown by the selected constructor of <code>T</code>.</del>
<p/>
<del>-16- <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.</del>
</p>
</blockquote>
<pre>
<del>constexpr optional(T&amp;&amp; v);</del>
</pre>
<blockquote>
<p>
<del>-17- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
<del>-18- <i>Effects:</i> Initializes the contained value as if direct-non-list-initializing an object of type <code>T</code> 
with the expression <code>std::move(v)</code>.</del>
<p/>
<del>-19- <i>Postcondition:</i> <code>*this</code> contains a value.</del>
<p/>
<del>-20- <i>Throws:</i> Any exception thrown by the selected constructor of <code>T</code>.</del>
<p/>
<del>-21- <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.</del>
</p>
</blockquote>
<pre>
template &lt;class... Args&gt; constexpr explicit optional(in_place_t, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-22- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-26- <i>Remarks:</i> If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, 
this constructor shall be a <tt>constexpr</tt> constructor. <ins>This constructor shall not participate in overload
resolution unless <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U, class... Args&gt;
  constexpr explicit optional(in_place_t, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is 
<tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-31- <i>Remarks:</i> <del>The function</del><ins>This constructor</ins> shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>. 
If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor.
</p>
</blockquote>
<p>
<ins>[<i>Note:</i> The following constructors are conditionally specified
as explicit. 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 = T&gt;
  <em>EXPLICIT</em> 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>, <tt>is_same_v&lt;U, 
in_place_t&gt;</tt> is <tt>false</tt>, and <tt>is_same_v&lt;optional&lt;T&gt;, decay_t&lt;U&gt;&gt;</tt> 
is <tt>false</tt>. The constructor is explicit 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;
  <em>EXPLICIT</em> 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> 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_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&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>. 
The constructor is explicit 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;
  <em>EXPLICIT</em> 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> 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_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&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>. The constructor 
is explicit 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>Change 20.6.3.3 [optional.object.assign] as indicated:</p>

<blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-4- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_copy_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-8- <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 copy constructor, no effect. If an exception is thrown
during the call to <tt>T</tt>'s copy assignment, the state of its contained value is as defined by the exception
safety guarantee of <tt>T</tt>'s copy assignment. <ins>This operator shall be defined as deleted unless
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and <tt>is_copy_assignable_v&lt;T&gt;</tt> is
<tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-13- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:
</p>
<blockquote><pre>
is_nothrow_move_assignable_v&lt;T&gt; &amp;&amp; is_nothrow_move_constructible_v&lt;T&gt;
</pre></blockquote>
<p>
-14- 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 move constructor, the state of <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move constructor. If an exception is 
thrown during the call to <tt>T</tt>'s move assignment, the state of <tt>*val</tt> and <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move assignment. <ins>This operator 
shall not participate in overload resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is 
<tt>true</tt> and <tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U <ins>= T</ins>&gt; optional&lt;T&gt;&amp; operator=(U&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-15- <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>.</del>
<p/>
[&hellip;]
<p/>
-19- <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. <del>The</del><ins>This</ins> function
shall not participate in overload resolution unless <del><tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt></del> 
<ins><tt>is_same_v&lt;optional&lt;T&gt;, decay_t&lt;U&gt;&gt;</tt> is <tt>false</tt>, 
<tt>is_constructible_v&lt;T, U&gt;</tt> is <tt>true</tt>, and 
<tt>is_assignable_v&lt;T&amp;, U&gt;</tt></ins> is <tt>true</tt>.
<p/>
<del>-20- <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>Effects</i>: See Table ?.</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. 
This function shall not participate in overload resolution unless <tt>is_constructible_v&lt;T, const U&amp;&gt;</tt> is 
<tt>true</tt>, <tt>is_assignable_v&lt;T&amp;, const U&amp;&gt;</tt> is <tt>true</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
and <tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&amp;&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>Effects</i>: See Table ?. 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. This function shall not participate in overload resolution unless <tt>is_constructible_v&lt;T, U&gt;</tt> is 
<tt>true</tt>, <tt>is_assignable_v&lt;T&amp;, U&gt;</tt> is <tt>true</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible&lt;const optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible&lt;optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
and <tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>.</ins>
</p>
</blockquote>

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

</blockquote>
  


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

<ol>
<li><p>Modify 20.6.3 [optional.object] as indicated:</p>

<blockquote>
<pre>
template &lt;class T&gt; class optional
{
public:
  using value_type = T;
  
  <i>// 20.6.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>);
  <del>constexpr optional(const T &amp;);</del>
  <del>constexpr optional(T &amp;&amp;);</del>
  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 = T&gt; <em>EXPLICIT</em> constexpr optional(U &amp;&amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(const optional&lt;U&gt; &amp;);
  template &lt;class U&gt; <em>EXPLICIT</em> optional(optional&lt;U&gt; &amp;&amp;);</ins>
  
  [&hellip;]
  
  <i>// 20.6.3.3, Assignment</i>
  optional &amp;operator=(nullopt_t) noexcept;
  optional &amp;operator=(const optional &amp;);
  optional &amp;operator=(optional &amp;&amp;) noexcept(<i>see below</i>);
  template &lt;class U <ins>= T</ins>&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>Change 20.6.3.1 [optional.object.ctor] as indicated:</p>

<blockquote>
<pre>
optional(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-3- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
<ins>-?- <i>Remarks:</i> This constructor shall be defined as deleted
unless <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-7- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-11- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to <tt>is_nothrow_move_constructible_v&lt;T&gt;</tt>.
<ins>This constructor shall not participate in overload resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
<del>constexpr optional(const T&amp; v);</del>
</pre>
<blockquote>
<p>
<del>-12- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
<del>-13- <i>Effects:</i> Initializes the contained value as if direct-non-list-initializing an object of type <code>T</code> 
with the expression <code>v</code>.</del>
<p/>
<del>-14- <i>Postcondition:</i> <code>*this</code> contains a value.</del>
<p/>
<del>-15- <i>Throws:</i> Any exception thrown by the selected constructor of <code>T</code>.</del>
<p/>
<del>-16- <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.</del>
</p>
</blockquote>
<pre>
<del>constexpr optional(T&amp;&amp; v);</del>
</pre>
<blockquote>
<p>
<del>-17- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
<del>-18- <i>Effects:</i> Initializes the contained value as if direct-non-list-initializing an object of type <code>T</code> 
with the expression <code>std::move(v)</code>.</del>
<p/>
<del>-19- <i>Postcondition:</i> <code>*this</code> contains a value.</del>
<p/>
<del>-20- <i>Throws:</i> Any exception thrown by the selected constructor of <code>T</code>.</del>
<p/>
<del>-21- <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.</del>
</p>
</blockquote>
<pre>
template &lt;class... Args&gt; constexpr explicit optional(in_place_t, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-22- <i>Requires:</i> <tt>is_constructible_v&lt;T, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-26- <i>Remarks:</i> If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, 
this constructor shall be a <tt>constexpr</tt> constructor. <ins>This constructor shall not participate in overload
resolution unless <tt>is_constructible_v&lt;T, Args...&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U, class... Args&gt;
  constexpr explicit optional(in_place_t, initializer_list&lt;U&gt; il, Args&amp;&amp;... args);
</pre>
<blockquote>
<p>
<del>-27- <i>Requires:</i> <tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is 
<tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-31- <i>Remarks:</i> <del>The function</del><ins>This constructor</ins> shall not participate in overload resolution unless 
<tt>is_constructible_v&lt;T, initializer_list&lt;U&gt;&amp;, Args&amp;&amp;...&gt;</tt> is <tt>true</tt>. 
If <tt>T</tt>'s constructor selected for the initialization is a <tt>constexpr</tt> constructor, this constructor 
shall be a <tt>constexpr</tt> constructor.
</p>
</blockquote>
<p>
<ins>[<i>Note:</i> The following constructors are conditionally specified
as explicit. 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 = T&gt;
  <em>EXPLICIT</em> 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>, <tt>is_same_v&lt;U, 
in_place_t&gt;</tt> is <tt>false</tt>, and <tt>is_same_v&lt;optional&lt;T&gt;, decay_t&lt;U&gt;&gt;</tt> 
is <tt>false</tt>. The constructor is explicit 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;
  <em>EXPLICIT</em> 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> 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_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&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>. 
The constructor is explicit 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;
  <em>EXPLICIT</em> 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> 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_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&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>. The constructor 
is explicit 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>Change 20.6.3.3 [optional.object.assign] as indicated:</p>

<blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(const optional&lt;T&gt;&amp; rhs);
</pre>
<blockquote>
<p>
<del>-4- <i>Requires:</i> <tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_copy_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-8- <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 copy constructor, no effect. If an exception is thrown
during the call to <tt>T</tt>'s copy assignment, the state of its contained value is as defined by the exception
safety guarantee of <tt>T</tt>'s copy assignment. <ins>This operator shall be defined as deleted unless
<tt>is_copy_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and <tt>is_copy_assignable_v&lt;T&gt;</tt> is
<tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
optional&lt;T&gt;&amp; operator=(optional&lt;T&gt;&amp;&amp; rhs) noexcept(<i>see below</i>);
</pre>
<blockquote>
<p>
<del>-9- <i>Requires:</i> <tt>is_move_constructible_v&lt;T&gt;</tt> is <tt>true</tt> and 
<tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</del>
<p/>
[&hellip;]
<p/>
-13- <i>Remarks:</i> The expression inside <tt>noexcept</tt> is equivalent to:
</p>
<blockquote><pre>
is_nothrow_move_assignable_v&lt;T&gt; &amp;&amp; is_nothrow_move_constructible_v&lt;T&gt;
</pre></blockquote>
<p>
-14- 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 move constructor, the state of <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move constructor. If an exception is 
thrown during the call to <tt>T</tt>'s move assignment, the state of <tt>*val</tt> and <tt>*rhs.val</tt> 
is determined by the exception safety guarantee of <tt>T</tt>'s move assignment. <ins>This operator 
shall not participate in overload resolution unless <tt>is_move_constructible_v&lt;T&gt;</tt> is 
<tt>true</tt> and <tt>is_move_assignable_v&lt;T&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
<pre>
template &lt;class U <ins>= T</ins>&gt; optional&lt;T&gt;&amp; operator=(U&amp;&amp; v);
</pre>
<blockquote>
<p>
<del>-15- <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>.</del>
<p/>
[&hellip;]
<p/>
-19- <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. <del>The</del><ins>This</ins> function
shall not participate in overload resolution unless <del><tt>is_same_v&lt;decay_t&lt;U&gt;, T&gt;</tt></del> 
<ins><tt>is_same_v&lt;optional&lt;T&gt;, decay_t&lt;U&gt;&gt;</tt> is <tt>false</tt>,
conjunction_v&lt;is_scalar&lt;T&gt;, is_same&lt;T, decay_t&lt;U&gt;&gt;&gt; is <tt>false</tt>,
<tt>is_constructible_v&lt;T, U&gt;</tt> is <tt>true</tt>, and 
<tt>is_assignable_v&lt;T&amp;, U&gt;</tt></ins> is <tt>true</tt>.
<p/>
<del>-20- <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>Effects</i>: See Table ?.</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. 
This function shall not participate in overload resolution unless <tt>is_constructible_v&lt;T, const U&amp;&gt;</tt> is 
<tt>true</tt>, <tt>is_assignable_v&lt;T&amp;, const U&amp;&gt;</tt> is <tt>true</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
and <tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&amp;&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>Effects</i>: See Table ?. 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. This function shall not participate in overload resolution unless <tt>is_constructible_v&lt;T, U&gt;</tt> is 
<tt>true</tt>, <tt>is_assignable_v&lt;T&amp;, U&gt;</tt> is <tt>true</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_constructible_v&lt;T, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible_v&lt;const optional&lt;U&gt;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible&lt;const optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_convertible&lt;optional&lt;U&gt;&amp;&amp;, T&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&gt;</tt> is <tt>false</tt>,
<tt>is_assignable_v&lt;T&amp;, const optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>,
and <tt>is_assignable_v&lt;T&amp;, optional&lt;U&gt;&amp;&amp;&gt;</tt> is <tt>false</tt>.</ins>
</p>
</blockquote>

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





<hr>
<h3><a name="2758" href="#2758">2758.</a> <tt>std::string{}.assign("ABCDE", 0, 1)</tt> is ambiguous</h3>
<p><b>Section:</b> 21.3.1.6.3 [string::assign] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Marshall Clow <b>Opened:</b> 2016-07-30 <b>Last modified:</b> 2016-10-16</p>
<p><b>Priority: </b>1
</p>
<p><b>View all other</b> <a href="lwg-index.html#string::assign">issues</a> in [string::assign].</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>
Before C++17, we had the following signature to <tt>std::basic_string</tt>:
</p>
<blockquote><pre>
basic_string&amp;
  assign(const basic_string&amp; str, size_type pos, size_type n = npos);
</pre></blockquote>
<p>
Unlike most of the other member functions on <tt>std::basic_string</tt>, there were not corresponding
versions that take a <tt>charT*</tt> or <tt>(charT *, size)</tt>.
<p/>
In <a href="http://wg21.link/p0254r2">p0254r2</a>, we (I) added:
</p>
<blockquote><pre>
basic_string&amp;
  assign(basic_string_view&lt;charT, traits&gt; sv, size_type pos, size_type n = npos);
</pre></blockquote>
<p>
which made the code above ambiguous. There are two conversions from "<tt>const charT*</tt>", 
one to <tt>basic_string</tt>, and the other to <tt>basic_string_view</tt>, and they're both equally 
good (in the view of the compiler).
<p/>
This ambiguity also occurs with the calls
</p>
<blockquote><pre>
insert(size_type pos1, const basic_string&amp; str,             size_type pos2, size_type n = npos);
insert(size_type pos1, basic_string_view&lt;charT, traits&gt; sv, size_type pos2, size_type n = npos);
</pre></blockquote>
<p>
but I will file a separate issue (<a href="lwg-active.html#2757">2757</a>) for that.
<p/>
A solution is to add <em>even more</em> overloads to <tt>assign</tt>, to make it match all the other member
functions of <tt>basic_string</tt>, which come in fours (<tt>string</tt>, <tt>pointer</tt>, <tt>pointer + size</tt>, 
<tt>string_view</tt>).
</p>

<p><i>[2016-08-03, Chicago, Robert Douglas provides wording]</i></p>


<p><i>[2016-08-05, Tim Song comments]</i></p>

<p>
On the assumption that the <tt>basic_string</tt> version is untouchable, I like the updated P/R, with a couple comments:
</p>
<ol>
<li><p>If it's constraining on <tt>is_convertible</tt> to <tt>basic_string_view</tt>, then I think it should take 
by reference to avoid copying <tt>T</tt>, which can be arbitrarily expensive. Both <tt>const T&amp;</tt> and 
<tt>T&amp;&amp;</tt> should work; the question is whether to accommodate non-const <tt>operator basic_string_view()</tt>s 
(which arguably shouldn't exist).</p></li>
<li><p>Minor issue: <tt>compare</tt> tests <tt>is_convertible</tt> and then uses direct-initialization syntax 
(which is <tt>is_constructible</tt>). They should match, because it's possible to have <tt>basic_string_view sv = t;</tt> 
succeed yet <tt>basic_string_view sv(t);</tt> fail.</p></li>
</ol>

<p><i>[2016-08-05, Chicago LWG]</i></p>

<ol>
<li>breaking ABI was a non-starter</li>
<li>we want to convert <tt>char const*</tt> to <tt>basic_string_view</tt> if possible</li>
<li>we want to take the original type by reference, to avoid new user string types from being copied</li>
<li>it is unfortunate that each length of string literal will generate a new entry in the symbol table</li>
</ol>
<p>Given feedback from discussion, we wish to go with the <tt>is_convertible_v</tt> method, but change:</p>
<ol>
<li>the function parameter type to <tt>T const&amp;</tt> for each overload</li>
<li>the parameter type in <tt>is_convertible_v</tt> to <tt>T const&amp;</tt></li>
<li>the initialization of <tt>sv(t)</tt> to <tt>sv = t</tt></li>
</ol>

<p><i>[2016-08, Chicago]</i></p>

<p>Fri PM: Move to Tentatively Ready</p>

<p><i>[2016-08-16, Jonathan Wakeley reopens]</i></p>

<p>
The P/R is not correct, the new overloads get chosen in preference to
the overloads taking <tt>const char*</tt> when passed a <tt>char*</tt>:
</p>
<blockquote><pre>
#include &lt;string&gt;

int main () {
  std::string str("a");
  char c = 'b';
  str.replace(0, 1, &amp;c, 1);
  if (str[0] != 'b')
    __builtin_abort();
}
</pre></blockquote>
<p>
With the resolution of 2758 this is now equivalent to:
</p>
<blockquote><pre>
str.replace(0, 1, string_view{&amp;c, 1}, 1);
</pre></blockquote>
<p>
which replaces the character with <tt>string_view{"b", 1}.substr(1, npos)</tt>
i.e. an empty string.
<p/>
The SFINAE constraints need to disable the new overloads for (at
least) the case of non-const <tt>value_type*</tt> arguments.
<p/>
I've implemented an alternative resolution, which would be specified as:
</p>
<blockquote><p>
<i>Remarks:</i> This function shall not participate in overload resolution
unless <tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is
<tt>true</tt> <ins>and <tt>is_convertible_v&lt;const T&amp;, const charT*&gt;</tt> is <tt>false</tt></ins>.
</p></blockquote>
<p>
All the overloads have the same problem.
<p/>
This program prints no output in C++14, and we should make sure it prints no output in C++17 too:
</p>
<blockquote><pre>
#include &lt;string&gt;

int main()
{
  std::string str("a");
  char c[1] = { 'b' };
  str.append(c, 1);
  if (str != "ab")
    puts("bad append");
  str.assign(c, 1);
  if (str != "b")
    puts("bad assign");
  str.insert(0, c, 1);
  if (str != "bb")
    puts("bad insert");
  str.replace(0, 2, c, 1);
  if (str != "b")
    puts("bad replace");
  if (str.compare(0, 1, c, 1))
    puts("bad compare");
}
</pre></blockquote>
<p>
Ville and I considered "<tt>is_same_v&lt;decay_t&lt;T&gt;, char*&gt;</tt> is <tt>false</tt>" but
that would still select the wrong overload for an array of const <tt>char</tt>,
because the new function template would be preferred to doing an array-to-pointer conversion to 
call the old overload.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Ville to provide updated wording; Marshall to implement</p>
  
<p><i>[2016-10-05]</i></p>

<p>
Ville provides revised wording.
</p>

<p><i>[2016-10 Telecom]</i></p>

<p>Ville's wording has been implemented in libstdc++ and libc++. Move this to Tentatively Ready and <a href="lwg-active.html#2757">2757</a> to Tentatively Resolved</p>


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

<ol>
<li><p>In 21.3.1 [basic.string] modify the synopsis for <tt>basic_string</tt> as follows:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt;&gt;
  class basic_string {
  public:
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; append(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; assign(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; insert(size_type pos1, <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos2, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; replace(size_type pos1, size_type n1,
                          <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                          size_type pos2, size_type n2 = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    int compare(size_type pos1, size_type n1,
                <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                size_type pos2, size_type n2 = npos) const;
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li><p>In 21.3.1.6.2 [string::append], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; append(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos, size_type n = npos);
</pre>
<blockquote>
<p>
-7- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; sv.size()</tt>.
<p/>
-8- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length 
<tt>rlen</tt> of the string to append as the smaller of <tt>n</tt> and <tt>sv.size() - pos</tt> 
and calls <tt>append(sv.data() + pos, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-9- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.3.1.6.3 [string::assign], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; assign(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos, size_type n = npos);
</pre>
<blockquote>
<p>
-9- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; sv.size()</tt>.
<p/>
-10- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length 
<tt>rlen</tt> of the string to assign as the smaller of <tt>n</tt> and <tt>sv.size() - pos</tt> 
and calls <tt>assign(sv.data() + pos, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-11- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>


<li><p>In 21.3.1.6.4 [string::insert], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; insert(size_type pos1, <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos2, size_type n = npos);
</pre>
<blockquote>
<p>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; sv.size()</tt>.
<p/>
-7- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length <tt>rlen</tt> 
of the string to assign as the smaller of <tt>n</tt> and <tt>sv.size() - pos2</tt> and calls 
<tt>insert(pos1, sv.data() + pos2, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-8- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.3.1.6.6 [string::replace], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; replace(size_type pos1, size_type n1, 
                     <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos2, size_type n2 = npos);
</pre>
<blockquote>
<p>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; sv.size()</tt>.
<p/>
-7- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length <tt>rlen</tt> 
of the string to be inserted as the smaller of <tt>n2</tt> and <tt>sv.size() - pos2</tt> and calls 
<tt>replace(pos1, n1, sv.data() + pos2, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
<p/>
-8- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.3.1.7.9 [string::compare], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
int compare(size_type pos1, size_type n1,
            <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
            size_type pos2, size_type n2 = npos) const;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
<ins>{</ins>
  <ins>basic_string_view&lt;charT, traits&gt; sv = t;</ins>
  return basic_string_view&lt;charT, traits&gt;(this.data(), pos1, n1).compare(sv, pos2, n2);
<ins>}</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>
</blockquote>

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

<ol>
<li><p>In 21.3.1 [basic.string] modify the synopsis for <tt>basic_string</tt> as follows:</p>

<blockquote>
<pre>
namespace std {
  template&lt;class charT, class traits = char_traits&lt;charT&gt;,
    class Allocator = allocator&lt;charT&gt;&gt;
  class basic_string {
  public:
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; append(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; assign(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; insert(size_type pos1, <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                         size_type pos2, size_type n = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    basic_string&amp; replace(size_type pos1, size_type n1,
                          <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                          size_type pos2, size_type n2 = npos);
    [&hellip;]
    <ins>template&lt;class T&gt;</ins>
    int compare(size_type pos1, size_type n1,
                <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                size_type pos2, size_type n2 = npos) const;
    [&hellip;]
  };
}
</pre>
</blockquote>
</li>

<li><p>In 21.3.1.6.2 [string::append], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; append(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos, size_type n = npos);
</pre>
<blockquote>
<p>
-7- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; sv.size()</tt>.
<p/>
-8- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length 
<tt>rlen</tt> of the string to append as the smaller of <tt>n</tt> and <tt>sv.size() - pos</tt> 
and calls <tt>append(sv.data() + pos, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>
and is_convertible_v&lt;const T&amp;, const charT*&gt; is <tt>false</tt>.</ins>
<p/>
-9- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.3.1.6.3 [string::assign], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; assign(<del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos, size_type n = npos);
</pre>
<blockquote>
<p>
-9- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos &gt; sv.size()</tt>.
<p/>
-10- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length 
<tt>rlen</tt> of the string to assign as the smaller of <tt>n</tt> and <tt>sv.size() - pos</tt> 
and calls <tt>assign(sv.data() + pos, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>
and is_convertible_v&lt;const T&amp;, const charT*&gt; is <tt>false</tt>.</ins>
<p/>
-11- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>


<li><p>In 21.3.1.6.4 [string::insert], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; insert(size_type pos1, <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos2, size_type n = npos);
</pre>
<blockquote>
<p>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; sv.size()</tt>.
<p/>
-7- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length <tt>rlen</tt> 
of the string to assign as the smaller of <tt>n</tt> and <tt>sv.size() - pos2</tt> and calls 
<tt>insert(pos1, sv.data() + pos2, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>
and is_convertible_v&lt;const T&amp;, const charT*&gt; is <tt>false</tt>.</ins>
<p/>
-8- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.3.1.6.6 [string::replace], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
basic_string&amp; replace(size_type pos1, size_type n1, 
                     <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
                     size_type pos2, size_type n2 = npos);
</pre>
<blockquote>
<p>
-6- <i>Throws:</i> <tt>out_of_range</tt> if <tt>pos1 &gt; size()</tt> or <tt>pos2 &gt; sv.size()</tt>.
<p/>
-7- <i>Effects:</i> <ins>Creates a variable, <tt>sv</tt>, as if by 
<tt>basic_string_view&lt;charT, traits&gt; sv = t</tt>.</ins> Determines the effective length <tt>rlen</tt> 
of the string to be inserted as the smaller of <tt>n2</tt> and <tt>sv.size() - pos2</tt> and calls 
<tt>replace(pos1, n1, sv.data() + pos2, rlen)</tt>.
<p/>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>
and is_convertible_v&lt;const T&amp;, const charT*&gt; is <tt>false</tt>.</ins>
<p/>
-8- <i>Returns:</i> <tt>*this</tt>.
</p>
</blockquote>
</blockquote>
</li>

<blockquote class="note">
<p>
[<i>Drafting note</i>: The wording changes below are for the same part of the standard as <a href="lwg-active.html#2771">2771</a>. 
However, they do not conflict. This one changes the definition of the routine, while the other changes the "Effects".
&mdash; <i>end drafting note</i>]
</p>
</blockquote>

<li><p>In 21.3.1.7.9 [string::compare], modify <tt>basic_string_view</tt> overload as follows:</p>

<blockquote>
<pre>
<ins>template&lt;class T&gt;</ins>
int compare(size_type pos1, size_type n1,
            <del>basic_string_view&lt;charT, traits&gt; sv</del><ins>const T&amp; t</ins>,
            size_type pos2, size_type n2 = npos) const;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to:
</p>
<blockquote><pre>
<ins>{</ins>
  <ins>basic_string_view&lt;charT, traits&gt; sv = t;</ins>
  return basic_string_view&lt;charT, traits&gt;(this.data(), pos1, n1).compare(sv, pos2, n2);
<ins>}</ins>
</pre></blockquote>
<p>
<ins>-?- <i>Remarks:</i> This function shall not participate in overload resolution unless
<tt>is_convertible_v&lt;const T&amp;, basic_string_view&lt;charT, traits&gt;&gt;</tt> is <tt>true</tt>
and is_convertible_v&lt;const T&amp;, const charT*&gt; is <tt>false</tt>.</ins>
</p>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2759" href="#2759">2759.</a> <tt>gcd</tt> / <tt>lcm</tt> and <tt>bool</tt> for the WP</h3>
<p><b>Section:</b> 26.8.13 [numeric.ops.gcd], 26.8.14 [numeric.ops.lcm] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Walter Brown <b>Opened:</b> 2016-08-01 <b>Last modified:</b> 2016-08-02</p>
<p><b>Priority: </b>Not Prioritized
</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>
With the acceptance of <tt>gcd</tt> and <tt>lcm</tt> in the working draft, the same problem as pointed out by
LWG <a href="lwg-active.html#2733">2733</a> exists here as well and should be fixed accordingly.
</p>

<p><i>[2016-08, Chicago]</i></p>

<p>Monday PM: Moved to Tentatively Ready</p>


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

<ol>
<li><p>Adjust 26.8.13 [numeric.ops.gcd] p2 as indicated:</p>

<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; gcd(M m, N n);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-2- <i>Remarks:</i> If either <tt>M</tt> or <tt>N</tt> is not an integer type, <ins>or if either is (possibly <i>cv</i>-qualified) 
<tt>bool</tt>,</ins> the program is ill-formed. 
</p>
</blockquote>
</blockquote>
</li>

<li><p>Adjust 26.8.14 [numeric.ops.lcm] p2 as indicated:</p>

<blockquote>
<pre>
template&lt;class M, class N&gt;
  constexpr common_type_t&lt;M, N&gt; lcm(M m, N n);
</pre>
<blockquote>
<p>
[&hellip;]
<p/>
-2- <i>Remarks:</i> If either <tt>M</tt> or <tt>N</tt> is not an integer type, <ins>or if either is (possibly <i>cv</i>-qualified) 
<tt>bool</tt>,</ins> the program is ill-formed. 
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2760" href="#2760">2760.</a> non-const <tt>basic_string::data</tt> should not invalidate iterators</h3>
<p><b>Section:</b> 21.3.1.1 [string.require] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Baker <b>Opened:</b> 2016-08-03 <b>Last modified:</b> 2016-08-08</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.require">active issues</a> in [string.require].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.require">issues</a> in [string.require].</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>
21.3.1.1 [string.require]/4 does not list non-const <tt>basic_string::data()</tt> as being a 
function that may be called with the guarantee that it will not invalidate references, pointers, and 
iterators to elements of a <tt>basic_string</tt> object.
</p>

<p><i>[2016-08 Chicago]</i></p>

<p>Wed PM: Move to Tentatively Ready</p>


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

<ol>
<li><p>Change 21.3.1.1 [string.require]/4 as indicated:</p>

<blockquote>
<p>
-4- References, pointers, and iterators referring to the elements of a <tt>basic_string</tt> sequence 
may be invalidated by the following uses of that <tt>basic_string</tt> object:
</p>
<ul>
<li><p>as an argument to any standard library function taking a reference to non-const <tt>basic_string</tt> as an
argument.(footnote 230)</p></li>
<li><p>Calling non-const member functions, except <tt>operator[]</tt>, <tt>at</tt>, <ins>data,</ins> <tt>front</tt>, 
<tt>back</tt>, <tt>begin</tt>, <tt>rbegin</tt>, <tt>end</tt>, and <tt>rend</tt>.</p></li>
</ul>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2765" href="#2765">2765.</a> Did LWG 1123 go too far?</h3>
<p><b>Section:</b> 27.5.3.1.6 [ios::Init] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Richard Smith <b>Opened:</b> 2016-08-13 <b>Last modified:</b> 2016-09-15</p>
<p><b>Priority: </b>0
</p>
<p><b>View all other</b> <a href="lwg-index.html#ios::Init">issues</a> in [ios::Init].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<a href="lwg-defects.html#1123">1123</a> fixed a bug where users of <tt>&lt;iostream&gt;</tt> were not guaranteed to have their streams flushed 
on program shutdown. However, it also added this rule:
</p>
<blockquote><p>
"Similarly, the entire program shall behave as if there were at least one instance of <tt>ios_base::Init</tt> with static 
lifetime."
</p></blockquote>
<p>
This seems pointless: it only affects the behavior of programs that never include <tt>&lt;iostream&gt;</tt> (because programs 
that do include it are already guaranteed at least one such instance), and those programs do not need an implicit flush 
because they cannot have written to the relevant streams.
<p/>
It's also actively harmful, because it requires the iostreams component to be linked into programs that do not use it, 
apparently even including freestanding implementations! Fortunately, C++ implementations appear to uniformly ignore this rule.
<p/>
Can it be removed?
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>P0; move to Tentatively Ready</p>


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

<ol>
<li><p>Modify 27.5.3.1.6 [ios::Init] p3 as indicated:</p>
<blockquote><p>
-3- The objects are constructed and the associations are established at some time prior to or during the first
time an object of class <tt>ios_base::Init</tt> is constructed, and in any case before the body of <tt>main</tt> begins
execution.(footnote 293) The objects are not destroyed during program execution.(footnote 294) The results of including 
<tt>&lt;iostream&gt;</tt> in a translation unit shall be as if <tt>&lt;iostream&gt;</tt> defined an instance of 
<tt>ios_base::Init</tt> with static storage duration. <del>Similarly, the entire program shall behave as if there were at 
least one instance of <tt>ios_base::Init</tt> with static storage duration.</del>
</p></blockquote>
</li>
</ol>






<hr>
<h3><a name="2767" href="#2767">2767.</a> <tt>not_fn <i>call_wrapper</i></tt> can form invalid types</h3>
<p><b>Section:</b> 20.14.9 [func.not_fn] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2016-08-19 <b>Last modified:</b> 2016-09-11</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
The definition of the <tt><i>call_wrapper</i></tt> type in the C++17 CD means this
fails to compile:
</p>
<blockquote><pre>
#include &lt;functional&gt;

struct abc { virtual void f() const = 0; };
struct derived : abc{ void f() const { } };
struct F { bool operator()(abc&amp;) { return false; } };
bool b = std::not_fn(F{})(derived{});
</pre></blockquote>
<p>
The problem is that the return types use <tt>result_of_t&lt;F(abc)&gt;</tt> and
<tt>F(abc)</tt> is not a valid function type, because it takes an abstract
class by value.
<p/>
The return types should use <tt>result_of_t&lt;F(Args<ins>&amp;&amp;</ins>...)&gt;</tt> instead.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>P0; move to Tentatively Ready</p>


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

<ol>
<li><p>Modify 20.14.9 [func.not_fn], class <tt><i>call_wrapper</i></tt> synopsis, as indicated:</p>
<blockquote>
<pre>
class <i>call_wrapper</i>
{
  [&hellip;]
  template&lt;class... Args&gt;
    auto operator()(Args&amp;&amp;...) &amp;
      -&gt; decltype(!declval&lt;result_of_t&lt;FD&amp;(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
  template&lt;class... Args&gt;
    auto operator()(Args&amp;&amp;...) const&amp;
      -&gt; decltype(!declval&lt;result_of_t&lt;FD const&amp;(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
  template&lt;class... Args&gt;
    auto operator()(Args&amp;&amp;...) &amp;&amp;
      -&gt; decltype(!declval&lt;result_of_t&lt;FD(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
  template&lt;class... Args&gt;
    auto operator()(Args&amp;&amp;...) const&amp;&amp;
      -&gt; decltype(!declval&lt;result_of_t&lt;FD const(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());  
  [&hellip;]
};
</pre>
</blockquote>
</li>

<li><p>Modify the prototype declarations of 20.14.9 [func.not_fn] as indicated:</p>
<blockquote>
<pre>
template&lt;class... Args&gt;
  auto operator()(Args&amp;&amp;... args) &amp;
    -&gt; decltype(!declval&lt;result_of_t&lt;FD&amp;(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
template&lt;class... Args&gt;
  auto operator()(Args&amp;&amp;... args) const&amp;
    -&gt; decltype(!declval&lt;result_of_t&lt;FD const&amp;(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
</pre>
<blockquote>
<p>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class... Args&gt;
  auto operator()(Args&amp;&amp;... args) &amp;&amp;
    -&gt; decltype(!declval&lt;result_of_t&lt;FD(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
template&lt;class... Args&gt;
  auto operator()(Args&amp;&amp;... args) const&amp;&amp;
    -&gt; decltype(!declval&lt;result_of_t&lt;FD const(Args<ins>&amp;&amp;</ins>...)&gt;&gt;());
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2768" href="#2768">2768.</a> <tt>any_cast</tt> and move semantics</h3>
<p><b>Section:</b> 20.8.4 [any.nonmembers] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Casey Carter <b>Opened:</b> 2016-08-27 <b>Last modified:</b> 2016-10-05</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#any.nonmembers">active issues</a> in [any.nonmembers].</p>
<p><b>View all other</b> <a href="lwg-index.html#any.nonmembers">issues</a> in [any.nonmembers].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
LWG <a href="lwg-defects.html#2509">2509</a> made two changes to the specification of <tt>any</tt> in v2 of the library fundamentals TS:
</p>

<ol>
<li>It altered the effects of the <tt>any_cast(any&amp;&amp;)</tt> overload to enable moving the value out of the <tt>any</tt> 
object and/or obtaining an rvalue reference to the contained value.</li>

<li>It made changes to support pathological copyable-but-not-movable contained values, which is madness.</li>
</ol>

<p>
Change 1 has very desirable effects; I propose that we apply the sane part of LWG <a href="lwg-defects.html#2509">2509</a> to <tt>any</tt> 
in the C++17 WP, for all of the reasons cited in the discussion of LWG <a href="lwg-defects.html#2509">2509</a>.
</p>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>P0; move to Tentatively Ready</p>

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

<ol>
<li><p>In 20.8.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>
<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, <tt>std::forward&lt;ValueType&gt;(*any_cast&lt;remove_reference_t&lt;ValueType&gt;&gt;(&amp;operand))</tt>.</ins>
</p>
<p>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>

</blockquote>


<p><b>Proposed resolution:</b></p>
<p>
Resolved by the wording provided by LWG <a href="lwg-active.html#2769">2769</a>.
</p>






<hr>
<h3><a name="2771" href="#2771">2771.</a> Broken <i>Effects</i> of some <tt>basic_string::compare</tt> functions in terms of <tt>basic_string_view</tt></h3>
<p><b>Section:</b> 21.3.1.7.9 [string::compare] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2016-09-05 <b>Last modified:</b> 2016-10-16</p>
<p><b>Priority: </b>1
</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>
Some <tt>basic_string::compare</tt> functions are specified in terms of a non-existing <tt>basic_string_view</tt>
constructor, namely 21.3.1.7.9 [string::compare] p3,
</p>
<blockquote><pre>
return basic_string_view&lt;charT, traits&gt;(this.data(), pos1, n1).compare(sv);
</pre></blockquote>
<p>
and 21.3.1.7.9 [string::compare] p4:
</p>
<blockquote><pre>
return basic_string_view&lt;charT, traits&gt;(this.data(), pos1, n1).compare(sv, pos2, n2);
</pre></blockquote>
<p>
because there doesn't exist a <tt>basic_string_view</tt> constructor with three arguments.
<p/>
Albeit this can be easily fixed by a proper combination of the existing constructor
</p>
<blockquote><pre>
constexpr basic_string_view(const charT* str, size_type len);
</pre></blockquote>
<p>
with the additional member function
</p>
<blockquote><pre>
constexpr basic_string_view substr(size_type pos = 0, size_type n = npos) const;
</pre></blockquote>
<p>
it should be decided whether adding the seemingly natural constructor
</p>
<blockquote><pre>
constexpr basic_string_view(const charT* str, size_type pos, size_type n);
</pre></blockquote>
<p>
could simplify matters. A counter argument for this addition might be, that <tt>basic_string</tt>
doesn't provide this constructor either.
<p/>
Another problem is related to the specification of 21.3.1.7.9 [string::compare] p4, which attempts to
call a non-existing <tt>basic_string_view::compare</tt> overload that would match the signature:
</p>
<blockquote><pre>
constexpr int compare(basic_string_view str, size_type pos1, size_type n1) const;
</pre></blockquote>

<p><i>[2016-09-09 Issues Resolution Telecom]</i></p>

<p>Marshall to investigate using P/R vs. adding the missing constructor.</p>

<p><i>[2016-10 Issues Resolution Telecom]</i></p>

<p>Marshall reports that P/R is better. Status to Tentatively Ready</p>


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

<blockquote class="note">
<p>
[<i>Drafting note</i>: The wording changes below are for the same part of the standard as <a href="lwg-active.html#2758">2758</a>. 
However, they do not conflict. This one changes the "Effects" of the routine, while the other changes the definition.
&mdash; <i>end drafting note</i>]
</p>
</blockquote>

<ol>
<li><p>Change 21.3.1.7.9 [string::compare] as indicated:</p>

<blockquote>
<pre>
int compare(size_type pos1, size_type n1,
            basic_string_view&lt;charT, traits&gt; sv) const;
</pre>
<blockquote>
<p>
-3- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
return basic_string_view&lt;charT, traits&gt;(<del>this.</del>data(), <ins>size()).substr(</ins>pos1, n1).compare(sv);
</pre>
</blockquote>
</blockquote>
<pre>
int compare(size_type pos1, size_type n1,
            basic_string_view&lt;charT, traits&gt; sv,
            size_type pos2, size_type n2 = npos) const;
</pre>
<blockquote>
<p>
-4- <i>Effects:</i> Equivalent to:
</p>
<blockquote>
<pre>
return basic_string_view&lt;charT, traits&gt;(<del>this.</del>data(), <ins>size()).substr(</ins>pos1, n1).compare(sv<del>,</del><ins>.substr(</ins>pos2, n2<ins>)</ins>);
</pre>
</blockquote>
</blockquote>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2773" href="#2773">2773.</a> Making <tt>std::ignore constexpr</tt></h3>
<p><b>Section:</b> 20.5.1 [tuple.general] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Vincent Reverdy <b>Opened:</b> 2016-09-10 <b>Last modified:</b> 2016-10-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#tuple.general">active issues</a> in [tuple.general].</p>
<p><b>View all other</b> <a href="lwg-index.html#tuple.general">issues</a> in [tuple.general].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
Currently <tt>std::ignore</tt> is not specified <tt>constexpr</tt> according to the C++ draft N4606 in the paragraph 
20.5.1 [tuple.general]. It prevents some use in <tt>constexpr</tt> context: for example declaring a 
<tt>constexpr</tt> variable equals to the result of a function to which <tt>std::ignore</tt> has been passed as a parameter:
</p>
<blockquote><pre>
constexpr int i = f(std::ignore); // Won't compile
</pre></blockquote>
<p>
If there is no fundamental reason preventing <tt>std::ignore</tt> to be <tt>constexpr</tt>, then we propose to declare 
it as <tt>constexpr</tt> instead of as <tt>const</tt>.
</p>

<p><i>[Issues processing Telecom 2016-10-7]</i></p>

<p>P0; set to Tentatively Ready</p>


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

<ol>
<li><p>Modify 20.5.1 [tuple.general] as indicated:</p>
<blockquote>
<pre>
<i>// 20.5.2.4, tuple creation functions:</i>
<del>const</del><ins>constexpr</ins> <i>unspecified</i> ignore;
</pre>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="2777" href="#2777">2777.</a> <tt>basic_string_view::copy</tt> should use <tt>char_traits::copy</tt></h3>
<p><b>Section:</b> 21.4.2.6 [string.view.ops], 21.3.1.6.7 [string::copy] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2016-09-27 <b>Last modified:</b> 2016-10-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>basic_string_view::copy</tt> is inconsistent with <tt>basic_string::copy</tt>, in that the
former uses <tt>copy_n</tt> and the latter uses <tt>traits::copy</tt>. We should have this
handling be consistent. 
<p/>
Moreover, the <tt>basic_string::copy</tt> description is excessively roundabout due to
copy-on-write era wording.
</p>

<p><i>[Issues processing Telecom 2016-10-7]</i></p>

<p>P0; set to Tentatively Ready</p>
<p>Removed "Note to project editor", since the issue there has been fixed in the current draft.</p>


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

<ol>
<li><p>Change 21.3.1.6.7 [string::copy] as indicated:</p>

<blockquote>
<pre>
size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre>

</blockquote>
<p>
<ins>-?- Let <tt>rlen</tt> be the smaller of <tt>n</tt> and <tt>size() - pos</tt>.</ins>
</p>
<p>
-2- <em>Throws: </em><tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
</p>
<p>
<ins>-?- <em>Requires:</em> <tt>[s, s + rlen)</tt> is a valid range.</ins>
</p>
<p>
-3- <em>Effects:</em> <del>Determines the effective length <tt>rlen</tt> of the string
to copy as the smaller of <tt>n</tt> and <tt>size() - pos</tt>. <tt>s</tt> shall
designate an array of at least <tt>rlen</tt> elements.</del><ins>Equivalent to: <tt>traits::copy(s, data() + pos, rlen)</tt>.
[<em>Note:</em> This does not terminate <tt>s</tt> with a null object. &mdash; <em>end note</em>]</ins>
</p>
<p><del>The function then replaces the string designated by <tt>s</tt> with a string of
length <tt>rlen</tt> whose elements are a copy of the string controlled by
<tt>*this</tt> beginning at position <tt>pos</tt>.</del>
</p>
<p>
<del>The function does not append a null object to the string designated by <tt>s</tt>.</del>
</p>
<p>
-4- <em>Returns: </em><tt>rlen</tt>.
</p>
</li>

<li><p>Change 21.4.2.6 [string.view.ops] as indicated:</p>

<blockquote>
<pre>
size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre>

</blockquote>
<p>
-1- Let <tt>rlen</tt> be the smaller of <tt>n</tt> and <tt>size() - pos</tt>.
</p>
<p>
-2- <em>Throws:</em> <tt>out_of_range</tt> if <tt>pos &gt; size()</tt>.
</p>
<p>
-3- <em>Requires:</em> <tt>[s, s + rlen)</tt> is a valid range.
</p>
<p>
-4- <em>Effects:</em> Equivalent to: <del><tt>copy_n(begin() + pos, rlen, s)</tt></del><ins><tt>traits::copy(s, 
data() + pos, rlen)</tt></ins>
</p>
<p>
-5- <em>Returns:</em> <tt>rlen</tt>.
</p>
<p>
-6- <em>Complexity:</em> &#x1d4aa;(<tt>rlen</tt>).
</p>
</li>
</ol>






<hr>
<h3><a name="2778" href="#2778">2778.</a> <tt>basic_string_view</tt> is missing <tt>constexpr</tt></h3>
<p><b>Section:</b> 21.4 [string.view] <b>Status:</b> <a href="lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Billy Robert O'Neal III <b>Opened:</b> 2016-09-30 <b>Last modified:</b> 2016-10-07</p>
<p><b>Priority: </b>0
</p>
<p><b>View other</b> <a href="lwg-index-open.html#string.view">active issues</a> in [string.view].</p>
<p><b>View all other</b> <a href="lwg-index.html#string.view">issues</a> in [string.view].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Tentatively Ready">Tentatively Ready</a> status.</p>
<p><b>Discussion:</b></p>
<p>
<tt>basic_string_view</tt> was not updated to account for other library
machinery made <tt>constexpr</tt> in Oulu. Now that <tt>reverse_iterator</tt> is
<tt>constexpr</tt> there's no reason the reverse range functions can't be.
Also, now that we have C++14 relaxed <tt>constexpr</tt>, we can also take care
of the assignment operator and <tt>copy</tt>.
</p>

<p><i>[Issues processing Telecom 2016-10-7]</i></p>

<p>split off the copy into its' own issue <a href="lwg-active.html#2780">2780</a></p>
<p>P0; set what's left to Tentatively Ready</p>

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

<ol>
<li><p>In 21.4.2 [string.view.template], add <tt>constexpr</tt> to the assignment operator:</p>

<blockquote>
<pre>
<ins>constexpr </ins>basic_string_view&amp; operator=(const basic_string_view&amp;) noexcept = default;
</pre>
</blockquote>
</li>

<li><p>In 21.4.2 [string.view.template], add <tt>constexpr</tt> to the reverse range functions:</p>

<blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator rend() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crend() const noexcept;
</pre>
</blockquote>
</li>

<li><p>In 21.4.2.2 [string.view.iterators], add <tt>constexpr</tt> to the reverse range functions:</p>

<blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crbegin() const noexcept;
</pre>
<blockquote>
<p>
-6- <em>Returns:</em> <tt>const_reverse_iterator(end())</tt>
</p>
</blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rend() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crend() const noexcept;
</pre>
<blockquote>
<p>
-7- <em>Returns:</em> <tt>const_reverse_iterator(begin())</tt>
</p>
</blockquote>
</blockquote>
</li>

<li><p>In 21.4.2 [string.view.template], add <tt>constexpr</tt> to <tt>copy</tt>:</p>

<blockquote>
<pre>
<ins>constexpr </ins>size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre>
</blockquote>
</li>

<li><p>In 21.4.2.6 [string.view.ops], add <tt>constexpr</tt> to <tt>copy</tt>:</p>

<blockquote>
<pre>
<ins>constexpr </ins>size_type copy(charT* s, size_type n, size_type pos = 0) const;
</pre>
</blockquote>
</li>
</ol>
</blockquote>


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

<ol>
<li><p>In 21.4.2 [string.view.template], add <tt>constexpr</tt> to the assignment operator:</p>

<blockquote>
<pre>
<ins>constexpr </ins>basic_string_view&amp; operator=(const basic_string_view&amp;) noexcept = default;
</pre>
</blockquote>
</li>

<li><p>In 21.4.2 [string.view.template], add <tt>constexpr</tt> to the reverse range functions:</p>

<blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator rend() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crend() const noexcept;
</pre>
</blockquote>
</li>

<li><p>In 21.4.2.2 [string.view.iterators], add <tt>constexpr</tt> to the reverse range functions:</p>

<blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rbegin() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crbegin() const noexcept;
</pre>
<blockquote>
<p>
-6- <em>Returns:</em> <tt>const_reverse_iterator(end())</tt>
</p>
</blockquote>
<pre>
<ins>constexpr </ins>const_reverse_iterator rend() const noexcept;
<ins>constexpr </ins>const_reverse_iterator crend() const noexcept;
</pre>
<blockquote>
<p>
-7- <em>Returns:</em> <tt>const_reverse_iterator(begin())</tt>
</p>
</blockquote>
</blockquote>
</li>

</ol>






</body>
</html>
