The __cpp_lib_has_$foo macros seem to be using a different naming convention from our previous macros, where we had just __cpp_lib_$foo. Is this a deliberate change of direction?
On Thu, May 22, 2014 at 4:58 PM, Nelson, Clark <[email protected]>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: [email protected] [mailto:[email protected]] On Behalf Of Richard > Smith > Sent: Thursday, May 15, 2014 4:19 PM > To: Nelson, Clark > Cc: [email protected] ([email protected]) > Subject: Re: [SG10] Comments from Alisdair > > On Thu, May 15, 2014 at 4:13 PM, Nelson, Clark <[email protected]> > 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 > [email protected] > http://www.open-std.org/mailman/listinfo/features > >
_______________________________________________ Features mailing list [email protected] http://www.open-std.org/mailman/listinfo/features
