<html><head><meta charset="UTF-8">
<title>Wording for Networking PDTS ballot comment 011 (US-10)</title>
  <style type='text/css'>
  body {font-variant-ligatures: none;}
  p {text-align:justify}
  li {text-align:justify}
  blockquote.note, div.note
  {
          background-color:#E0E0E0;
          padding-left: 15px;
          padding-right: 15px;
          padding-top: 1px;
          padding-bottom: 1px;
  }
  p code {color:navy}
  ins p code {color:#00A000}
  p ins code {color:#00A000}
  p del code {color:#A00000}
  ins {color:#00A000}
  del {color:#A00000}
  table#boilerplate { border:0 }
  table#boilerplate td { padding-left: 2em }
  table.bordered, table.bordered th, table.bordered td {
    border: 1px solid;
    text-align: center;
  }
  ins.block {color:#00A000; text-decoration: none}
  del.block {color:#A00000; text-decoration: none}
  #hidedel:checked ~ * del, #hidedel:checked ~ * del * { display:none; visibility:hidden }
  </style>
</head><body>
<table id="boilerplate">
<tr><td>Document number</td><td>P0746R0</td></tr>
<tr><td>Date</td><td>2017-07-13</td></tr>
<tr><td>Project</td><td>Programming Language C++, Library Working Group</td></tr>
<tr><td>Reply-to</td><td>Jonathan Wakely &lt;cxx&#x40;kayari.org&gt;, Michael McLaughlin &lt;mikebmcl&#x40;gmail.com&gt;</td></tr>
</table><hr>
<h1>Wording for Networking PDTS ballot comment 011 (US-10)</h1>
<h2>Introduction</h2>

<p>This paper presents proposed changes in response to one of the National Body comments for PDTS 19216 from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4643.pdf">N4643</a>.</p>

<h2>Changes</h2>

<h3>NB comment 011 (US-10)</h3>

<blockquote><p>Without knowing more about what kind of executor is being used, a user will have difficulty deciding which of the three functions to use to add a task to an executor. It is preferable to limit the options for adding tasks to a generic executor. Concrete executors can add additional functions if required.</p>

<p><strong>Proposed change:</strong>
Remove the defer function from executors, as that is the least well-defined. This would match the existing Boost ASIO implementation.</p></blockquote>

<p>This was discussed by LEWG in Kona and rejected, then discussed again in Toronto due to the <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0703r0.html">P0703R0</a> paper. LEWG preferred to keep the <code>defer</code> function but add normative recommendation to distinguish it from <code>post</code>. The wording below was provided by Michael McLaughlin.</p>

<p>The change is to split the row for <code>post</code> and <code>defer</code> into two rows,
with differing normative wording.
The revised wording for <code>post</code> says "The executor may begin <code>f1</code>'s progress before the call to <code>post</code> completes."
The revised wording for <code>defer</code> says "The executor should not begin <code>f1</code>'s progress before the call to <code>defer</code> completes."</p>

<h2>Proposed Wording</h2>

<p>Changes are relative to <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/n4656.pdf">N4656</a>.</p>

<p>Modify 13.2.2 [async.reqmts.executor] Table 4 as shown:</p>

<blockquote><p><strong>expression</strong></p>

<p><code>x1.post(std::move(f), a)</code><br/>
<del><code>x1.defer(std::move(f), a)</code></del></p>

<p><strong>type</strong></p>

<p><em>[Drafting note: empty cell]</em></p>

<p><strong>assertion/note pre/post-condition</strong></p>

<p><em>Effects:</em> Creates an object <code>f1</code> initialized
with <em><code>DECAY_COPY</code></em><code>(forward&lt;Func&gt;(f))</code> in the
current thread of execution. Calls <code>f1()</code> at
most once. The executor shall not block
forward progress of the caller pending
completion of <code>f1()</code>.
<ins> The executor may begin f1's progress before the call to <code>post</code> completes. </ins>
Executor implementations
should use the supplied allocator to allocate
any memory required to store the function
object. Prior to invoking the function object,
the executor shall deallocate any memory
allocated. <em>[Note:</em> Executors deﬁned in this
Technical Speciﬁcation always use the supplied
allocator unless otherwise speciﬁed. <em>--end note]</em><br/>
<em>Synchronization:</em> The invocation of <code>post</code>
<del> or <code>defer</code> </del>
synchronizes with (C++Std [intro.multithread]) the invocation of <code>f1</code>.
<del>
<em>[Note:</em> Although the requirements placed on
<code>defer</code> are identical to <code>post</code>, the use of <code>post</code>
conveys a preference that the caller does not
block the ﬁrst step of <code>f1</code>'s progress, whereas
<code>defer</code> conveys a preference that the caller
does block the ﬁrst step of <code>f1</code>. One use of
<code>defer</code> is to convey the intention of the caller
that <code>f1</code> is a continuation of the current call
context. The executor may use this information
to optimize or otherwise adjust the way in
which <code>f1</code> is invoked. <em>--end note]</em>
</del></p>

<p><strong>expression</strong></p>

<p><ins><code>x1.defer(std::move(f), a)</code></ins></p>

<p><strong>type</strong></p>

<p><em>[Drafting note: empty cell]</em></p>

<p><strong>assertion/note pre/post-condition</strong></p>

<p><ins>
<em>Effects:</em> Creates an object <code>f1</code> initialized
with <em><code>DECAY_COPY</code></em><code>(forward&lt;Func&gt;(f))</code> in the
current thread of execution. Calls <code>f1()</code> at
most once. The executor shall not block
forward progress of the caller pending
completion of <code>f1()</code>.
The executor should not begin <code>f1</code>'s progress before the call to <code>defer</code> completes.
<em>[Note:</em> One use of <code>defer</code> is to convey
the intention of the caller that <code>f1</code> is a
continuation of the current call context. The
executor may use this information to optimize or
otherwise adjust the way in which <code>f1</code> is invoked.
<em>--end note]</em> Executor implementations should use
the supplied allocator to allocate any memory
required to store the function object. Prior to
invoking the function object, the executor
shall deallocate any memory allocated. <em>[Note:</em>
Executors defined in this Technical
Specification always use the supplied allocator
unless otherwise specified. <em>--end note]</em><br/>
<em>Synchronization:</em> The invocation of <code>defer</code>
synchronizes with (C++Std [intro.multithread])
the invocation of <code>f1</code>.
</ins></p></blockquote>
</body></html>
