OK, I have added entries for all of the library issues mentioned by
Alisdair. No macro for gets, but macros for the other three. For two of
them, no one gave any feedback, but I went ahead and filled in the obvious
values. They are all marked by editorial question marks.
Besides a few tweaks, those are the only changes since I posted it on April
Fool's Day. I plan to put the result (attached) into the mailing as N4030,
mainly so we can get more eyes on the __has_cpp_attribute feature.
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of Richard Smith
Sent: Thursday, May 15, 2014 4:19 PM
To: Nelson, Clark
Cc: email@example.com (firstname.lastname@example.org)
Subject: Re: [SG10] Comments from Alisdair
On Thu, May 15, 2014 at 4:13 PM, Nelson, Clark <email@example.com> wrote:
I got a few comments today about SD-6 from Alisdair Meredith. Most of them
were just pointing out that it needs to be updated, which we already knew,
and which is in progress. But there are a few I thought I should pass along.
> We added an 'is_final' type-trait at the last meeting too, not
> sure what name to recommend (issue 2112) and 'is_null_pointer' at
> Chicago (issue 2247)
> We added 'make_reverse_iterator' to the <iterator> header (issue
It came as news to me that we, as a committee, have added features to the
standard in response to issues (a.k.a. defect reports). Obviously, those of
us who feel that's a bad idea in general might want to suggest that we be
more careful to avoid that in the future. :-(
But apparently we have some water under the bridge, and SG10 needs to decide
whether these should have macros.
I think an is_final feature-detection macro makes a lot of sense. Libraries that want to do EBO could reasonably want to use is_final && is_empty if is_final exists, and fall back to just using is_empty otherwise.
> Finally, do we want a feature to detect that 'gets' has finally
> been removed? (NB comment GB 9 in N3733)
I'm not even going to try to frame this question. :-/ (This is library issue
2249, for anyone who wants more information.)
I don't see any value in a macro for gets. Code that doesn't use gets doesn't need the macro, and code that uses it is neither portable to C++14 nor correct :-)
> Oh, and as a point of curiosity, it turned out that there is no
> feature-detect macro for the C++11 feature I am trying to detect,
> alias templates! I am surprised at just how useful I am finding
> this feature at the moment, but mostly as a porting aid, saying
> "this old code is now implemented using that new more
> general/standard feature over there" (plus implementing the few
> places that standard library mandates them).
Is there anyone who thinks that this would not be a good idea? (This was
adopted from N2258.)
Features mailing list