Recent insertions for a few LWG issues seem to contradict the general policy set forth in paragraph 1 of section 3.4:
"The following table itemizes all the changes that were made to the working draft for C++14 as specified in a WG21 technical document. (Changes that were made as specified in a core or library issue are not included.)" I support the insertions, and therefore recommend that we reframe the (parenthesized sentence of the) policy statement. However, it is not clear to me what replacement policy we ought articulate: - Do we only include macros for resolved issues when explicitly requested by WG chairs? - Or for issues that introduce a new feature? - Or for issues that affect backward compatibility? - Or ought we leave the criteria open and just say something like "selected issues"? - Or …? -- WEB On May 22, 2014, at 6: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: [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? > <sd-6.htm>_______________________________________________ > 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
