<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"><<a href="mailto:clark.nelson@intel.com" target="_blank">clark.nelson@intel.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Maybe it doesn't matter for the purposes of SD-6, but for P0220R1<br>
> the shared_ptr changes for arrays were approved in Jacksonville, but<br>
> are not in the CD due to editorial conflicts. P0414R0 aims to<br>
> correct that.<br>
><br>
> Similarly, P0067R3 was approved in Oulu, but isn't in the CD because<br>
> the editor noticed inconsistencies in the wording which mean it<br>
> needs to be revised and go through LWG again.<br>
><br>
> If those features do make it back into the WP in time for C++17 the<br>
> date 201603 might not make sense for their macros. On the other hand<br>
> maybe it does still make sense, as the substance of the proposals<br>
> will still be what was voted on in Jacksonville and Oulu<br>
> respectively.<br>
<br>
</span>Hmm. Thanks for pointing these out.<br>
<br>
For P0067R3, which wasn'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'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't think I'm likely to consider the difference to be editorial, so (assuming that LWG doesn'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's even a little more<br>
complicated because it was only part of the paper.<br>
<br>
For the time being, I'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'd kind of rather not try to branch-predict. I think I'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>