Subject: Re: [SG10] P0074R0: Making std::owner_less more flexible
From: John Spicer (jhs_at_[hidden])
Date: 2016-02-23 15:47:11
I donât think I have a strong preference between updating based on the attachment vs. P0096R1.
Iâm not sure what, if any, is the process required/desired of such updates.
If there is no required process, then the attachment seems better than P0996R1.
> On Feb 23, 2016, at 4:14 PM, Nelson, Clark <clark.nelson_at_[hidden]> wrote:
> We really need to update SD-6 on isocpp.org before another meeting goes by.
> P0096R1 in the pre-Jacksonville mailing is lacking rationale for quite a few
> C++17 features added in Lenexa and Kona, but I think we're just going to
> have to live with that.
> But there's also a technical issue that I think we need to consider fixing.
> For P0074R0, the document currently says "none" for the macro (with
> editorial question marks) but also lists a value and a header. This is
> obviously incoherent.
> As was pointed out at the December 16 meeting, P0074 proposes a new
> application of the technique originally adopted from N3421 (Making Operator
> Functors greater<>). The suggestion was made that we consider updating the
> value of the associated macro: __cpp_lib_transparent_operators.
> That seems like a good idea, but there's a slight issue with it: for the
> C++14 feature, the macro is defined in <functional>, but the change in P0074
> applies to <memory>.
> So I'm tempted to suggest that an implementation that has P0074 should
> define __cpp_lib_transparent_operators to be 201510 in <memory> *and also*
> <functional>, whereas an implementation that has N3421 but not P0074 should
> define it to be 201210 in <functional> (only).
> Also, I got the section number wrong for that row; it should be 20.7,
> not 20.8. So I'd like to move it up a couple of rows.
> I have made the proposed changes in the attached document.
> Please reply indicating whether you would like me to update SD-6 based on
> the attachment, or on P0096R1 from the mailing -- or if you'd rather I not
> update it at all. (I think that pretty much exhausts the available
> alternatives, unless there's some other very small tweak to be made.)
> Clark Nelson Chair, PL22.16 (ANSI C++ standard committee)
> Intel Corporation Chair, SG10 (C++ SG for feature-testing)
> clark.nelson_at_[hidden] Chair, CPLEX (C SG for parallel language extensions)
> Features mailing list
SG10 list run by email@example.com