On 05/22/2014 07:58 PM, Nelson, Clark wrote:
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.

Clark


From: metafoo@gmail.com [mailto:metafoo@gmail.com] On Behalf Of Richard Smith
Sent: Thursday, May 15, 2014 4:19 PM
To: Nelson, Clark
Cc: features@isocpp.open-std.org (features@open-std.org)
Subject: Re: [SG10] Comments from Alisdair

On Thu, May 15, 2014 at 4:13 PM, Nelson, Clark <clark.nelson@intel.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
2285)
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.)

SGTM. __cpp_alias_templates?


_______________________________________________
Features mailing list
Features@isocpp.open-std.org
http://www.open-std.org/mailman/listinfo/features
Do we want in the examples
__has_include(<optional>), etc.
or
__has_include(<experimental/optional>), etc.

I thought the experimental headers aren't in with the std headers.

Or do I have that wrong?