<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN"
    "http://www.w3.org/TR/html4/strict.dtd">
<html>
<head>
<title>C++ Standard Library Issues Resolved Directly In Rapperswil, 2014</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}
</style>
</head>
<body>
<h1>C++ Standard Library Issues Resolved Directly In Rapperswil, 2014</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">N4079</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>Revised 2014-06-20</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">Alisdair Meredith &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2>Immediate Issues</h2>
<hr>
<h3><a name="2371"></a>2371. [fund.ts] No template aliases defined for new type traits</h3>
<p><b>Section:</b> 20.10.2 [meta.type.synop] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Joe Gottman <b>Opened:</b> 2014-03-07 <b>Last modified:</b> 2014-06-20</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>

<p>
The library fundamentals specification defines two new type trait template classes: <tt>invocation_type</tt> and <tt>raw_invocation_type</tt>.  
But it does not define the corresponding template aliases. Note that both of these classes define a member typedef <tt>type</tt> and no 
other public members, so according to the argument in <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3887.pdf">N3887</a> 
the template aliases should be defined.
</p>

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

<p>
Move as Immediate.
</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/2014/n3908.html">N3908</a>.</p>

<ol>
<li><p>Add the following to section 3.3.1[meta.type.synop] of the 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#meta">Library Fundamentals specification</a>
as indicated:
</p>

<blockquote><pre>
namespace std {
namespace experimental {
inline namespace fundamentals_v1 {
  [&hellip;]
  <i>// 3.3.2, Other type transformations</i>
  template &lt;class&gt; class invocation_type; <i>// not defined</i>
  template &lt;class F, class... ArgTypes&gt; class invocation_type&lt;F(ArgTypes...)&gt;;
  template &lt;class&gt; class raw_invocation_type; <i>// not defined</i>
  template &lt;class F, class... ArgTypes&gt; class raw_invocation_type&lt;F(ArgTypes...)&gt;;
  
  <ins>template &lt;class T&gt; 
    using invocation_type_t = typename invocation_type&lt;T&gt;::type;
  template &lt;class T&gt; 
    using raw_invocation_type_t = typename raw_invocation_type&lt;T&gt;::type;</ins>
  
} <i>// namespace fundamentals_v1</i>
} <i>// namespace experimental</i>
} <i>// namespace std</i>
</pre></blockquote>
</li>

</ol>





<hr>
<h3><a name="2374"></a>2374. [fund.ts] Remarks for <tt>optional::to_value</tt> are too restrictive</h3>
<p><b>Section:</b> X [optional.object.observe] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Jonathan Wakely <b>Opened:</b> 2014-03-25 <b>Last modified:</b> 2014-06-20</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>

<p>
In Bristol I think I claimed that the remarks for <tt>optional::to_value()</tt>
were unimplementable and the function could only be <tt>constexpr</tt> if both
constructors that could be called were <tt>constexpr</tt>, but I was wrong.
The remarks should be reverted to the original pre-n3793 form.
</p>

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

<p>
Move to Immediate
</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/2014/n3908.html">N3908</a>.</p>

<ol>
<li><p>Change [optional.object.observe] p23 of the 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#optional.object.observe">Library Fundamentals specification</a>
as indicated:
</p>

<blockquote><pre>
template &lt;class U&gt; constexpr T value_or(U&amp;&amp; v) const &amp;;
</pre><blockquote>
<p>
[&hellip;]
<p/>
-23- <i>Remarks</i>: If <del>both constructors of <tt>T</tt> which could be selected are <tt>constexpr</tt> constructors</del><ins>the 
selected constructor of <tt>T</tt> is a <tt>constexpr</tt> constructor</ins>, this function 
shall be a <tt>constexpr</tt> function. 
</p>
</blockquote>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="2389"></a>2389. [fund.ts] <tt>function::operator=</tt> is over-specified and handles allocators incorrectly</h3>
<p><b>Section:</b> X [mods.func.wrap] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Pablo Halpern <b>Opened:</b> 2014-05-23 <b>Last modified:</b> 2014-06-20</p>
<p><b>View other</b> <a href="lwg-index-open.html#mods.func.wrap">active issues</a> in [mods.func.wrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#mods.func.wrap">issues</a> in [mods.func.wrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>

<p>
This issue against the TS is similar to LWG <a href="lwg-active.html#2386">2386</a>, which is against the standard. The Effects clauses for the assignment 
operator for class template <tt>function</tt> are written as code that constructs a temporary <tt>function</tt> and then swaps it 
with <tt>*this</tt>. 
The intention appears to be that assignment should have the strong exception guarantee, i.e., <tt>*this</tt> is not modified if 
an exception is thrown. The description in the standard is incorrect when <tt>*this</tt> was originally constructed using an 
allocator. The TS attempts to correct the problem, but the correction is incomplete.
<p/>
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#mods.func.wrap">The wording in the TS</a> uses 
<tt>get_memory_resource()</tt> to construct a temporary <tt>function</tt> object with the same allocator as the left-hand size 
(lhs) of the assignment. The intended result of using this pattern was that the allocator for <tt>*this</tt> would be unchanged, 
but it doesn't quite work. The problem is that the allocator returned by <tt>get_memory_resource()</tt> is not the same type as 
the type-erased allocator used to construct the <tt>function</tt> object, but rather a type-erased distillation of that type that 
is insufficient for making a true copy of the allocator. The rules for type-erased allocators in the TS 
(<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#memory.type.erased.allocator">[memory.type.erased.allocator]</a>) 
specify that the lifetime of the object returned by <tt>get_memory_resource()</tt> is sometimes tied to the lifetime of <tt>*this</tt>, 
which might cause the (single copy of) the allocator to be destroyed if the <tt>swap</tt> operation destroys and reconstructs <tt>*this</tt>, 
as some implementations do (and are allowed to do).
<p/>
The desired behavior is that assignment would leave the allocator of the lhs unchanged. The way to achieve this behavior is to 
construct the temporary <tt>function</tt> using the original allocator. Unfortunately, we cannot describe the desired behavior in 
pure code, because <tt>get_memory_resource()</tt> does not really name the type-erased allocator, as mentioned above. The PR below, 
therefore, uses pseudo-code, inventing a fictitious <tt><i>ALLOCATOR_OF</i>(f)</tt> expression that evaluates to the actual allocator 
type, even if that allocator was type erased. I have implemented this PR successfully.
</p>

<p><i>[2014-06-18, Rapperswil]</i></p>

<p>
Move to Immediate (after removing the previous "Throws: Nothing" element to prevent an editorial conflict with
<a href="lwg-active.html#2401">2401</a>).
</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/2014/n3908.html">N3908</a>.</p>

<ol>
<li><p>Change in [mods.func.wrap] in the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#mods.func.wrap">Library TS</a> 
as indicated:
</p>
<blockquote>
<p>
<ins>In the following descriptions, let <tt><i>ALLOCATOR_OF</i>(f)</tt> be the allocator specified in the construction of <tt>function</tt> 
<tt>f</tt>, or <tt>allocator&lt;char&gt;()</tt> if no allocator was specified.</ins>
</p>
<pre>
function&amp; operator=(const function&amp; f);
</pre>
<blockquote>
<p>
-5- <i>Effects</i>: <tt>function(allocator_arg, <del>get_memory_resource()</del><ins><i>ALLOCATOR_OF</i>(*this)</ins>, f).swap(*this);</tt>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
function&amp; operator=(function&amp;&amp; f);
</pre>
<blockquote>
<p>
-8- <i>Effects</i>: <tt>function(allocator_arg, <del>get_memory_resource()</del><ins><i>ALLOCATOR_OF</i>(*this)</ins>, std::move(f)).swap(*this);</tt>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
function&amp; operator=(nullptr_t);
</pre>
<blockquote>
<p>
-11- <i>Effects</i>: If <tt>*this != NULL</tt>, destroys the target of <tt>this</tt>.
<p/>
-12- <i>Postconditions</i>: <tt>!(*this)</tt>. <ins>The memory resource returned by <tt>get_memory_resource()</tt> after the assignment 
is equivalent to the memory resource before the assignment. [<i>Note</i>: the address returned by <tt>get_memory_resource()</tt> 
might change &mdash; <i>end note</i>]</ins>
<p/>
-13- <i>Returns</i>: <tt>*this</tt>  
</p>
</blockquote>
<pre>
template&lt;class F&gt; function&amp; operator=(F&amp;&amp; f);
</pre>
<blockquote>
<p>
-15- <i>Effects</i>: <tt>function(allocator_arg, <del>get_memory_resource()</del><ins><i>ALLOCATOR_OF</i>(*this)</ins>, 
std::forward&lt;F&gt;(f)).swap(*this);</tt>
<p/>
[&hellip;]
</p>
</blockquote>
<pre>
template&lt;class F&gt; function&amp; operator=(reference_wrapper&lt;F&gt; f);
</pre>
<blockquote>
<p>
-18- <i>Effects</i>: <tt>function(allocator_arg, <del>get_memory_resource()</del><ins><i>ALLOCATOR_OF</i>(*this)</ins>, f).swap(*this);</tt>
<p/>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>
</ol>





<hr>
<h3><a name="2390"></a>2390. [fund.ts] Invocation types and rvalues</h3>
<p><b>Section:</b> X [mods.func.wrap] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Michael Spertus <b>Opened:</b> 2014-05-26 <b>Last modified:</b> 2014-06-20</p>
<p><b>View other</b> <a href="lwg-index-open.html#mods.func.wrap">active issues</a> in [mods.func.wrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#mods.func.wrap">issues</a> in [mods.func.wrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>

<p>
<tt>invocation_type</tt> falls short of its stated goals in the following case. Using the notation of 
<a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3866.html">Invocation type traits</a>, 
consider
</p>
<blockquote>
<pre>
void f(int const&amp; i);
more_perfect_forwarding_async(f, int(7)); // Oops. Dangling reference because rvalue gone when async runs
</pre>
</blockquote>
<p>
This was always the advertised intent of the proposal, but while the language reflects this for the first parameter in the 
case of a member pointer, it failed to include corresponding language for other parameters.
</p>

<p><i>[2014-06-18, Rapperswil]</i></p>

<p>
Mike Spertus, Richard Smith, Jonathan Wakely, and Jeffrey Yasskin suggest improved wording.
</p>

<strong>Previous resolution [SUPERSEDED]:</strong>
<p/>
<blockquote class="note">
<p>This wording is relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html">N3908</a>.</p>

<ol>
<li><p>Change Table 3, [meta.trans.other] in the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3908.html#meta.trans.other">Library TS</a> 
as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 3 &mdash; Other type transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

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

<tr>
<td>
<tt>template &lt;class Fn, class... ArgTypes&gt;<br/>
struct invocation_type&lt;Fn(ArgTypes...)&gt;;</tt>
</td>
<td>
<tt>Fn</tt> and all types in the parameter pack <tt>ArgTypes</tt><br/>
shall be complete types, (possibly <i>cv</i>-qualified) <tt>void</tt>,<br/> 
or arrays of unknown bound. 
</td>
<td>
If <ins><tt>A1, A2,...</tt> denotes <tt>ArgTypes...</tt> and</ins><br/> 
<tt>raw_invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt><br/> 
is the function type <tt>R(T1, T2, ...)</tt> <ins>then let <tt>Ui</tt> be<br/> 
<tt>decay&lt;Ai&gt;::type</tt> if <tt>Ai</tt> is an rvalue otherwise <tt>Ti</tt>.<br/> 
If</ins> <del>and</del> <tt>Fn</tt> is a pointer to member type and <tt>T1</tt> is<br/>
an rvalue reference, then <ins>let <tt>U1</tt> be</ins> <tt><del>R(</del>decay&lt;T1&gt;::type<del>,<br/> 
T2, ...)</del></tt>.<br/> 
<del>Otherwise, <tt>raw_invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt></del><br/>
<ins>The member typedef <tt>type</tt> shall equal <tt>R(U1, U2, ...)</tt></ins>.
</td>
</tr>

</table>
</blockquote>

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


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

<ol>
<li><p>Change Table 3, [meta.trans.other] in the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4023.html#meta.trans.other">Library TS</a> 
as indicated:
</p>
<blockquote>
<table border="1">
<caption>Table 3 &mdash; Other type transformations</caption>
<tr>
<th align="center">Template</th>
<th align="center">Condition</th>
<th align="center">Comments</th>
</tr>

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

<tr>
<td>
<tt>template &lt;class Fn, class... ArgTypes&gt;<br/>
struct invocation_type&lt;Fn(ArgTypes...)&gt;;</tt>
</td>
<td>
<tt>Fn</tt> and all types in the parameter pack <tt>ArgTypes</tt><br/>
shall be complete types, (possibly <i>cv</i>-qualified) <tt>void</tt>,<br/> 
or arrays of unknown bound. 
</td>
<td>
<ins>
The nested typedef <tt>invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt><br/> 
shall be defined as follows. If<br/>
<tt>raw_invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt><br/> 
does not exist, there shall be no member typedef <tt>type</tt>. Otherwise:<br/>
<ul>
<li><p><ins>Let <tt>A1, A2,</tt> &hellip; denote <tt>ArgTypes...</tt></ins></p></li>
<li><p><ins>Let <tt>R(T1, T2, &hellip;)</tt> denote<br/>
<tt>raw_invocation_type_t&lt;Fn(ArgTypes...)&gt;</tt></ins></p></li>
<li><p><ins>Then the member typedef <tt>type</tt> shall name the function<br/>
type <tt>R(U1, U2, &hellip;)</tt> where <tt>Ui</tt> is <tt>decay_t&lt;Ai&gt;</tt><br/> 
if <tt>declval&lt;Ai&gt;()</tt> is an rvalue otherwise <tt>Ti</tt>.</ins></p></li>
</ul>
</ins>
<del>If <tt>raw_invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt><br/> 
is the function type <tt>R(T1, T2, &hellip;)</tt> <br/> 
and <tt>Fn</tt> is a pointer to member type and <tt>T1</tt> is<br/>
an rvalue reference, then <tt>R(decay&lt;T1&gt;::type,<br/> 
T2, &hellip;)</tt>.<br/> 
Otherwise, <tt>raw_invocation_type&lt;Fn(ArgTypes...)&gt;::type</tt>.<br/></del>
</td>
</tr>

</table>
</blockquote>

</li>
</ol>





<hr>
<h3><a name="2395"></a>2395. [fund.ts] <i>Preconditions:</i> is defined nowhere</h3>
<p><b>Section:</b> X [mods.func.wrap], X [memory.resource.priv], X [memory.polymorphic.allocator.ctor], X [memory.polymorphic.allocator.mem], X [memory.resource.pool.ctor], X [memory.resource.monotonic.buffer.ctor] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Zhihao Yuan <b>Opened:</b> 2014-06-09 <b>Last modified:</b> 2014-06-20</p>
<p><b>View other</b> <a href="lwg-index-open.html#mods.func.wrap">active issues</a> in [mods.func.wrap].</p>
<p><b>View all other</b> <a href="lwg-index.html#mods.func.wrap">issues</a> in [mods.func.wrap].</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>

<p>
This element has been introduced by <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n3916.pdf">N3916</a>, 
but the standard does not define it. The standard defines <i>Requires:</i> to indicate a precondition 
(17.5.1.4 [structure.specifications] p3).
<p/>
<em>Proposed wording</em>:
<p/>
Substitute all <i>Preconditions:</i> with <i>Requires:</i>.
</p>

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

<p>
Move to Immediate
</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/2014/n4023.html">N4023</a>.</p>

<ol>
<li><p>Substitute all <i>Preconditions:</i> with <i>Requires:</i>.</p></li>
</ol>





<hr>
<h3><a name="2409"></a>2409. [fund.ts] SFINAE-friendly <tt>common_type/iterator_traits</tt> should be removed from the fundamental-ts</h3>
<p><b>Section:</b> X [mods.meta.trans.other], X [mods.iterator.traits] <b>Status:</b> <a href="lwg-active.html#Immediate">Immediate</a>
 <b>Submitter:</b> Daniel Kr&uuml;gler <b>Opened:</b> 2014-06-19 <b>Last modified:</b> 2014-06-20</p>
<p><b>View all issues with</b> <a href="lwg-status.html#Immediate">Immediate</a> status.</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts</b></p>
<p>
During the Rapperswil meeting the proposal <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2014/n4041.html">N4041</a>
had been discussed and there seemed to be strong consensus to apply the SFINAE-friendly definitions
that currently exist within the fundamentals-ts to the C++17 working draft. If this happens, the fundamentals-ts 
needs to remove its own specification regarding these templates. This issue requests this change to happen.
</p>


<p><b>Proposed resolution:</b></p>
<p>This wording is relative to N4023 in regard to fundamental-ts changes.</p>

<ol>
<li><p>In fundamental-ts, change Table 2 &mdash; "Significant features in this technical specification" as
indicated:</p>

<blockquote>
<table border="1">
<caption>Table 2 &mdash; Significant features in this technical specification</caption>
<tr>
<th align="center">Doc.<br/>No.</th>
<th align="center">Title</th>
<th align="center">Primary<br/>Section</th>
<th align="center">Macro Name Suffix</th>
<th align="center">Value</th>
<th align="center">Header</th>
</tr>

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

<tr>
<td>
<del>N3843</del><br/>
</td>
<td>
<del>A SFINAE-<br/>Friendly<br/><tt>common_type</tt></del>
</td>
<td>
<del>2.4 [mods.meta.trans.other]</del><br/>
</td>
<td>
<del><tt>common_type_sfinae</tt></del>
</td>
<td>
<del><tt>201402</tt></del>
</td>
<td>
<del><tt>&lt;type_traits&gt;</tt></del><br/>
</td>
</tr>

<tr>
<td>
<del>N3843</del><br/>
</td>
<td>
<del>A SFINAE-<br/>Friendly<br/><tt>iterator_traits</tt></del>
</td>
<td>
<del>2.5 [mods.iterator.traits]</del><br/>
</td>
<td>
<del><tt>iterator_traits_sfinae</tt></del>
</td>
<td>
<del><tt>201402</tt></del>
</td>
<td>
<del><tt>&lt;iterator&gt;</tt></del><br/>
</td>
</tr>

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

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

<li><p>In fundamental-ts, remove the existing sub-clause 2.4 [mods.meta.trans.other] in its entirety:</p>

<p>
<del><b>2.4 Changes to <tt>std::common_type</tt> [mods.meta.trans.other]</b></del>
</p>
<blockquote>
<p>
<del>-1- [&hellip;]</del>
</p>
</blockquote>

</li>

<li><p>In fundamental-ts, remove the existing sub-clause 2.5 [mods.iterator.traits] in its entirety:</p>

<p>
<del><b>2.5 Changes to <tt>std::iterator_traits</tt> [mods.iterator.traits]</b></del>
</p>
<blockquote>
<p>
<del>-1- [&hellip;]</del>
</p>
</blockquote>
</li>

</ol>





</body>
</html>
