<!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++ Library Fundamentals TS Issues to be moved in Kona</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++ Library Fundamentals TS Issues to be moved in Kona</h1>
<table>
<tr>
<td align="left">Doc. no.</td>
<td align="left">P2704R0</td>
</tr>
<tr>
<td align="left">Date:</td>
<td align="left"><p>2022-11-07</p>
</td>
</tr>
<tr>
<td align="left">Audience:</td>
<td align="left">WG21</td>
</tr>
<tr>
<td align="left">Reply to:</td>
<td align="left">Jonathan Wakely &lt;<a href="mailto:lwgchair@gmail.com">lwgchair@gmail.com</a>&gt;</td>
</tr>
</table>
<h2 id="tentatively_ready">Tentatively Ready Issues</h2>
<hr>
<h3><a name="3136" href="https://cplusplus.github.io/LWG/lwg-active.html#3136">3136</a>. [fund.ts.v3] LFTSv3 awkward wording in <tt>propagate_const</tt> requirements</h3>
<p><b>Section:</b> 3.2.2.2.1 [fund.ts.v3::propagate_const.class_type_requirements] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2018-07-02 <b>Last modified:</b> 2022-10-19</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v3</b></p>
<p>
In the LFTSv3 prospective-working-paper <a href="https://wg21.link/n4758">N4758</a>, [propagate_const.class_type_requirements] 
uses a strange turn of phrase:
</p>
<blockquote><p>
"In this sub-clause, <tt>t</tt> denotes a non-<tt>const</tt> lvalue of type <tt>T</tt>, <tt>ct</tt> is a <tt>const T&amp;</tt> 
bound to <tt>t</tt>, [&hellip;]"
</p></blockquote>
<p>
The last bit is strange: "<tt>ct</tt> is a <tt>const T&amp;</tt> bound to <tt>t</tt>" is not how we usually say things. 
The specification-variables usually denote values, and values can't be references. Perhaps we could just say, 
"<tt>ct</tt> is <tt>as_const(t)</tt>"?
</p>

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

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

<ol>
<li>
<p>
Edit 3.2.2.2.1 [fund.ts.v3::propagate_const.class_type_requirements] as indicated:
</p>
<blockquote>
<p>
-1- If <tt>T</tt> is class type then it shall satisfy the following requirements. In this sub-clause <tt>t</tt> denotes 
a non-<tt>const</tt> lvalue of type <tt>T</tt>, <tt>ct</tt> is <del>a 
<tt>const T&amp;</tt> bound to <tt>t</tt></del><ins><tt>as_const(t)</tt></ins>, <tt>element_type</tt> denotes an object type. 
</p>
</blockquote>
</li>
</ol>
</blockquote>

<p><i>[2022-10-12; Jonathan provides improved wording]</i></p>


<p><i>[2022-10-19; Reflector poll]</i></p>

<p>
Set status to "Tentatively Ready" after eight votes in favour in reflector poll.
</p>



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

<p>
This wording is relative to <a href="https://wg21.link/N4920">N4920</a>.
</p>

<ol>
<li>
<p>
Edit 3.2.2.2 [fund.ts.v3::propagate_const.requirements] as indicated:
</p>
<blockquote>
<p>-1-
<code>T</code> shall be
<ins>a cv-unqualified pointer-to-object type</ins>
<del>an object pointer type</del>
or a <ins>cv-unqualified</ins>
class type for which
<code>decltype(*declval&lt;T&amp;&gt;())</code> is an lvalue reference
<ins>to object type</ins>;
otherwise the program is ill-formed.
</p>
<p><del>-2-
If <code>T</code> is an array type, reference type, pointer to function type or
pointer to (possibly cv-qualified) <code>void</code>, then the program is
ill-formed.
</del>
</p>
<p>-3-
[<em>Note:</em>
<code>propagate_const&lt;const int*&gt;</code> is well-formed
<ins>but propagate_const&lt;int* const&gt; is not.</ins>
&mdash; <em>end note</em>]
</p>
</blockquote>
</li>

<li>
<p>
Edit 3.2.2.2.1 [fund.ts.v3::propagate_const.class_type_requirements] as indicated:
</p>
<blockquote>
<p>-1-
If <tt>T</tt> is class type then it shall satisfy the following requirements.
In this sub-clause <tt>t</tt> denotes
<del>a non-<tt>const</tt></del><ins>an</ins>
lvalue of type <tt>T</tt>, <tt>ct</tt>
<del>is a <tt>const T&amp;</tt> bound to <tt>t</tt>, <tt>element_type</tt> denotes an object type.</del>
<ins>denotes <tt>as_const(t)</tt>.</ins>
</p>
</blockquote>
</li>
</ol>






<hr>
<h3><a name="3411" href="https://cplusplus.github.io/LWG/lwg-active.html#3411">3411</a>. [fund.ts.v3] Contradictory namespace rules in the Library Fundamentals TS</h3>
<p><b>Section:</b> 5.4 [fund.ts.v3::memory.resource.syn] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Thomas K&ouml;ppe <b>Opened:</b> 2020-02-28 <b>Last modified:</b> 2022-10-19</p>
<p><b>Priority: </b>3
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v3</b></p>
<p>
The Library Fundamentals TS, <a href="https://wg21.link/n4840">N4840</a>, 
contains <a href="https://wg21.link/n4840#general.namespaces">a rule about 
the use of namespaces (paragraph 1)</a>, with the consequence:
</p>
<blockquote><p>
"This TS does not define <tt>std::experimental::fundamentals_v3::pmr</tt>"
</p></blockquote>
<p>
However, the TS then <a href="https://wg21.link/n4840#memory.resource.syn">goes on to 
define exactly that namespace</a>.
<p/>
At the time when the subclause memory.resource.syn was added, the IS didn't use to contain 
a namespace <tt>pmr</tt>. When the IS adopted that namespace and the TS was rebased, the 
namespace rule started conflicting with the material in the TS.
<p/>
I do not have a workable proposed resolution at this point.
</p>

<p><i>[2020-04-07 Issue Prioritization]</i></p>

<p>Priority to 3 after reflector discussion.</p>

<p><i>[2021-11-17; Jiang An comments and provides wording]</i></p>

<p>
Given namespaces <tt>std::chrono::experimental::fundamentals_v2</tt> and <tt>std::experimental::fundamentals_v2::pmr</tt> 
are used in LFTS v2, I think that the intent is that
</p>
<ul>
<li><p>the prefix <tt>experimental::fundamentals_v<i>N</i></tt> is only added to a namespace specified by the 
standard, and</p></li>
<li><p>every name specified by the standard in the outer namespace of that of the related component in the TS.</p></li>
</ul>
<p>
If we follow the convention, perhaps we should relocate <tt>resource_adaptor</tt> from 
<tt>std::experimental::fundamentals_v3::pmr</tt> to <tt>std::pmr::experimental::fundamentals_v3</tt> in LFTS v3.
If it's decided that <tt>resource_adaptor</tt> shouldn't be relocated, I suppose that LWG 3411 can be by striking 
the wrong wording in 1.3 [fund.ts.v3::general.namespaces] and using qualified <tt>std::pmr::memory_resource</tt> 
when needed.
</p>
<p><strong>Previous resolution [SUPERSEDED]:</strong></p>
<blockquote class="note">
<p>
This wording is relative to <a href="https://wg21.link/N4853">N4853</a>.
</p>

<blockquote class="note">
<p>
[<i>Drafting Note:</i> Two mutually exclusive options are prepared, depicted below by <b>Option A</b> and 
<b>Option B</b>, respectively.] 
</p>
</blockquote>

<p>
<b>Option A:</b>
</p>

<ol>

<li><p>Modify 1.3 [fund.ts.v3::general.namespaces] as indicated:</p>

<blockquote>
<p>
-2- Each header described in this technical specification shall import the contents of 
<tt><ins><i>outer-namespace</i></ins><del>std</del>::experimental::fundamentals_v3</tt> 
into <tt><ins><i>outer-namespace</i></ins><del>std</del>::experimental</tt> as if by
</p>
<blockquote><pre>
namespace <ins><i>outer-namespace</i></ins><del>std</del>::experimental::inline fundamentals_v3 {}
</pre></blockquote>
<p>
<ins>where <tt><i>outer-namespace</i></tt> is a namespace defined in the C++ Standard Library.</ins>
</p>
</blockquote>
</li>

<li><p>Modify 5.3 [fund.ts.v3::memory.type.erased.allocator], Table 5, as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 5 &mdash; Computed <tt>memory_resource</tt> for type-erased allocator</caption>
<tr style="text-align:center">
<th>If the type of <tt>alloc</tt> is</th>
<th>then the value of <tt>rptr</tt> is</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>any other type meeting the <i></i> requirements (C++20 &para;16.5.3.5)</td>
<td>a pointer to a value of type <tt>pmr::<ins>experimental::</ins>resource_adaptor&lt;A&gt;</tt> where <tt>A</tt> 
is the type of <tt>alloc</tt>. <tt>rptr</tt> remains valid only for the lifetime of <tt>X</tt>.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>
</li>

<li><p>Modify 5.4 [fund.ts.v3::memory.resource.syn], header <tt>&lt;experimental/memory_resource&gt;</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::<ins>pmr::</ins>experimental::inline fundamentals_v3<del>::pmr</del> {
[&hellip;]
} // namespace std::<ins>pmr::</ins>experimental::inline fundamentals_v3<del>::pmr</del>
</pre>
</blockquote>
</li>

</ol>

<p>
<b>Option B:</b>
</p>

<ol>

<li><p>Modify 1.3 [fund.ts.v3::general.namespaces] as indicated:</p>

<blockquote>
<p>
-1- Since the extensions described in this technical specification are experimental and not part 
of the C++ standard library, they should not be declared directly within namespace <tt>std</tt>. 
Unless otherwise specified, all components described in this technical specification either: 
</p>
<ol style="list-style-type: none">
<li><p>&mdash; modify an existing interface in the C++ Standard Library in-place,</p></li>
<li><p>&mdash; are declared in a namespace whose name appends <tt>::experimental::fundamentals_v3</tt> to a 
namespace defined in the C++ Standard Library, such as <tt>std</tt> or <tt>std::chrono</tt>, or</p></li>
<li><p>&mdash; are declared in a subnamespace of a namespace described in the previous bullet<del>, whose name is 
not the same as an existing subnamespace of namespace <tt>std</tt></del>.</p></li>
</ol>
<p>
<del>[<i>Example:</i> This TS does not define <tt>std::experimental::fundamentals_v3::pmr</tt> because 
the C++ Standard Library defines <tt>std::pmr</tt>. &mdash; <i>end example</i>] </del>
</p>
</blockquote>
</li>

<li><p>Modify 4.2 [fund.ts.v3::func.wrap.func], class template <tt>function</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  namespace experimental::inline fundamentals_v3 {

    template&lt;class&gt; class function; <i>// undefined</i>

    template&lt;class R, class... ArgTypes&gt;
    class function&lt;R(ArgTypes...)&gt; {
    public:
      [&hellip;]
      <ins>std::</ins>pmr::memory_resource* get_memory_resource() const noexcept;
    };
[&hellip;]
} // namespace experimental::inline fundamentals_v3
[&hellip;]
} // namespace std
</pre>
</blockquote>
</li>

<li><p>Modify 5.3 [fund.ts.v3::memory.type.erased.allocator], Table 5, as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 5 &mdash; Computed <tt>memory_resource</tt> for type-erased allocator</caption>
<tr style="text-align:center">
<th>If the type of <tt>alloc</tt> is</th>
<th>then the value of <tt>rptr</tt> is</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>any other type meeting the <i></i> requirements (C++20 &para;16.5.3.5)</td>
<td>a pointer to a value of type <tt><ins>experimental::</ins>pmr::resource_adaptor&lt;A&gt;</tt> where <tt>A</tt> 
is the type of <tt>alloc</tt>. <tt>rptr</tt> remains valid only for the lifetime of <tt>X</tt>.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>
</li>

<li><p>Modify 5.5.1 [fund.ts.v3::memory.resource.adaptor.overview] as indicated:</p>

<blockquote>
<p>
-1- An instance of <tt>resource_adaptor&lt;Allocator&gt;</tt> is an adaptor that wraps a 
<tt><ins>std::pmr::</ins>memory_resource</tt> interface around <tt>Allocator</tt>. [&hellip;]
</p>
<blockquote>
<pre>
<i>// The name <tt>resource_adaptor_imp</tt> is for exposition only.</i>
template&lt;class Allocator&gt;
class <i>resource_adaptor_imp</i> : public <ins>std::pmr::</ins>memory_resource {
public:
  [&hellip;]
  
  virtual bool do_is_equal(const <ins>std::pmr::</ins>memory_resource&amp; other) const noexcept;
};
</pre>
</blockquote>
</blockquote>
</li>

<li><p>Modify 5.5.3 [fund.ts.v3::memory.resource.adaptor.mem] as indicated:</p>

<blockquote>
<pre>
-6- bool do_is_equal(const <ins>std::pmr::</ins>memory_resource&amp; other) const noexcept;
</pre>
<blockquote>
<p>
[&hellip;]
</p>
</blockquote>
</blockquote>
</li>

<li><p>Modify 7.2 [fund.ts.v3::futures.promise], class template <tt>promise</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  namespace experimental::inline fundamentals_v3 {

    template&lt;class R&gt;
    class promise {
    public:
      [&hellip;]
      <ins>std::</ins>pmr::memory_resource* get_memory_resource() const noexcept;
    };
[&hellip;]
} // namespace experimental::inline fundamentals_v3
[&hellip;]
} // namespace std
</pre>
</blockquote>
</li>

<li><p>Modify 7.3 [fund.ts.v3::futures.task], class template <tt>packaged_task</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std {
  namespace experimental::inline fundamentals_v3 {

    template&lt;class R, class... ArgTypes&gt;
    class packaged_task&lt;R(ArgTypes...)&gt; {
    public:
      [&hellip;]
      <ins>std::</ins>pmr::memory_resource* get_memory_resource() const noexcept;
    };
[&hellip;]
} // namespace experimental::inline fundamentals_v3
[&hellip;]
} // namespace std
</pre>
</blockquote>
</li>

</ol>
</blockquote>

<p><i>[2022-10-12; Jonathan provides updated wording]</i></p>

<p>
The LWG telecon decided on a simpler form of <b>Option A</b>.
The changes to 1.3 [fund.ts.v3::general.namespaces] generated some questions
and disagreement, but it was decided that they are not needed anyway.
The normative synopses already depict the use of inline namespaces with the
stated effects. That paragraph seems more informative than normative, and there
were suggestions to strike it entirely. It was decided to keep it but without
making the edits.  As such, it remains correct for the contents of
<tt>std::experimental::fundamentals_v3</tt>. It doesn't apply to
<tt>pmr::resource_adaptor</tt>, but is not <i>incorrect</i> for that either.
The rest of the proposed resolution fully specifies the <tt>pmr</tt> parts.
</p>

<p><i>[2022-10-19; Reflector poll]</i></p>

<p>
Set status to "Tentatively Ready" after eight votes in favour in reflector poll.
</p>



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

<ol>

<li><p>Modify 5.3 [fund.ts.v3::memory.type.erased.allocator], Table 5, as indicated:</p>

<blockquote>
<table border="1">
<caption>Table 5 &mdash; Computed <tt>memory_resource</tt> for type-erased allocator</caption>
<tr style="text-align:center">
<th>If the type of <tt>alloc</tt> is</th>
<th>then the value of <tt>rptr</tt> is</th>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
<tr>
<td>any other type meeting the <i></i> requirements (C++20 &para;16.5.3.5)</td>
<td>a pointer to a value of type <tt>pmr::<ins>experimental::</ins>resource_adaptor&lt;A&gt;</tt> where <tt>A</tt> 
is the type of <tt>alloc</tt>. <tt>rptr</tt> remains valid only for the lifetime of <tt>X</tt>.</td>
</tr>
<tr>
<td colspan="2" align="center">
<tt>[&hellip;]</tt>
</td>
</tr>
</table>
</blockquote>
</li>

<li><p>Modify 5.4 [fund.ts.v3::memory.resource.syn], header <tt>&lt;experimental/memory_resource&gt;</tt> 
synopsis, as indicated:</p>

<blockquote>
<pre>
namespace std::<ins>pmr::</ins>experimental::inline fundamentals_v3<del>::pmr</del> {
[&hellip;]
} // namespace std::<ins>pmr::</ins>experimental::inline fundamentals_v3<del>::pmr</del>
</pre>
</blockquote>
</li>

</ol>





<hr>
<h3><a name="3771" href="https://cplusplus.github.io/LWG/lwg-active.html#3771">3771</a>. [fund.ts.v3] remove binders typedefs from <code>function</code></h3>
<p><b>Section:</b> 99 [fund.ts.v3::func.wrap.func.overview] <b>Status:</b> <a href="https://cplusplus.github.io/LWG/lwg-active.html#Ready">Tentatively Ready</a>
 <b>Submitter:</b> Alisdair Meredith <b>Opened:</b> 2022-09-12 <b>Last modified:</b> 2022-09-23</p>
<p><b>Priority: </b>Not Prioritized
</p>
<p><b>Discussion:</b></p>
<p><b>Addresses: fund.ts.v3</b></p>
<p>
The LFTSv3 bases its specification for <code>experimental::function</code>
on <code>std::function</code> in the C++20 standard.
However, the wording was largely copied over from LFTSv2 which based its
wording on the C++14 standard.
</p>
<p>
For C++17, we removed the conditionally defined typedefs for the legacy binders
API, but this removal was not reflected in the TS.  We are now left with a
specification referring to unknown types, <tt>T1</tt> and <tt>T2</tt>.
</p>
<p>
 These typedefs should be excised to match the referenced standard.
</p>

<p><i>[2022-09-23; Reflector poll]</i></p>

<p>
Set status to Tentatively Ready after ten votes in favour during reflector poll.
</p>



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

<ol>
<li>
<p>Modify the synopsis in 99 [fund.ts.v3::func.wrap.func.overview]
as indicated:</p>

<blockquote><pre>
namespace std {
  namespace experimental::inline fundamentals_v3 {

    template&lt;class&gt; class function; <i>// undefined</i>

    template&lt;class R, class... ArgTypes&gt;
    class function&lt;R(ArgTypes...)&gt; {
    public:
      using result_type = R;
      <del>using argument_type = T1;</del>
      <del>using first_argument_type T1;</del>
      <del>using second_argument_type = T2;</del>

      using allocator_type = erased_type;

      // ...
  }
}
</pre></blockquote>
</li>
</ol>





</body>
</html>
