<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Tue, Jul 19, 2016 at 2:24 PM, Nelson, Clark <span dir="ltr">&lt;<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">&gt; Maybe it doesn&#39;t matter for the purposes of SD-6, but for P0220R1<br>
&gt; the shared_ptr changes for arrays were approved in Jacksonville, but<br>
&gt; are not in the CD due to editorial conflicts. P0414R0 aims to<br>
&gt; correct that.<br>
&gt;<br>
&gt; Similarly, P0067R3 was approved in Oulu, but isn&#39;t in the CD because<br>
&gt; the editor noticed inconsistencies in the wording which mean it<br>
&gt; needs to be revised and go through LWG again.<br>
&gt;<br>
&gt; If those features do make it back into the WP in time for C++17 the<br>
&gt; date 201603 might not make sense for their macros. On the other hand<br>
&gt; maybe it does still make sense, as the substance of the proposals<br>
&gt; will still be what was voted on in Jacksonville and Oulu<br>
&gt; respectively.<br>
<br>
</span>Hmm. Thanks for pointing these out.<br>
<br>
For P0067R3, which wasn&#39;t applied to the WD at all, the interesting<br>
question will be when and how R4 (or successor) makes it into the WD.<br>
If it&#39;s voted in at a subsequent meeting, we should probably use the date of<br>
that vote. But if the changes relative to R3 are considered to be editorial,<br>
there might conceivably not be another WG21 vote, in which case we should<br>
use the Oulu date. (But in either case, are we really going to try adding it<br>
to C++17 after the CD goes out?)<br></blockquote><div><br></div><div>IIUC, there will be at least one NB comment requesting we do so, since it only missed the CD due to a wording oversight. Having looked at R4, I don&#39;t think I&#39;m likely to consider the difference to be editorial, so (assuming that LWG doesn&#39;t say no to the NB comment) there should be a full committee motion to adopt the fixed wording.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
All the same considerations apply to P0220R1, but it&#39;s even a little more<br>
complicated because it was only part of the paper.<br>
<br>
For the time being, I&#39;m inclined to omit the row for P0067; I can always<br>
resurrect it later.<br></blockquote><div><br></div><div>Sounds good to me.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
For P0220, because of the complications of the row-spanning in the table,<br>
I&#39;d kind of rather not try to branch-predict. I think I&#39;ll touch base with<br>
Herb about his expectations.<br>
<span class="HOEnZb"><font color="#888888"><br>
Clark<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
Features mailing list<br>
<a href="mailto:Features@isocpp.open-std.org">Features@isocpp.open-std.org</a><br>
<a href="http://www.open-std.org/mailman/listinfo/features" rel="noreferrer" target="_blank">http://www.open-std.org/mailman/listinfo/features</a><br>
</div></div></blockquote></div><br></div></div>