Subject: Re: [SG10] Comments from Alisdair
From: W Brown (webrown.cpp_at_[hidden])
Date: 2014-05-22 19:47:53
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 ?
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.
> From: metafoo_at_[hidden] [mailto:metafoo_at_[hidden]] On Behalf Of Richard Smith
> Sent: Thursday, May 15, 2014 4:19 PM
> To: Nelson, Clark
> Cc: features_at_[hidden] (features_at_[hidden])
> Subject: Re: [SG10] Comments from Alisdair
> On Thu, May 15, 2014 at 4:13 PM, Nelson, Clark <clark.nelson_at_[hidden]> 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.)
> SGTM. __cpp_alias_templates?
> Features mailing list
SG10 list run by firstname.lastname@example.org