On 09/29/2014 03:46 PM, Richard Smith wrote:
> On Sun, Sep 28, 2014 at 5:17 PM, Ed Smith-Rowland <3dw4rd_at_[hidden]
> <mailto:3dw4rd_at_[hidden]>> wrote:
>
> On 08/14/2014 07:37 PM, Nelson, Clark wrote:
>> I have made a few minor revisions since N4030.
>>
>> The redlining in the document is relative to the published SD-6; I think
>> that's the way we'll want to publish it. But here is what I've changed
>> recently:
>>
>> In response to Ed Smith-Rowland's question about <optional> vs.
>> <experimental/optional> I updated the __has_include example. Of course it's
>> just an example, but I think it's more helpful now than it was.
>>
>> In response to Walter's question about the "policy" for the C++14 table, I
>> minimally tweaked the text. :-)
>>
>> In response to Richard's question/complaint, I deleted "has" from the macro
>> names for new features added by LWG issues.
>>
>> There are sentences in the rationale section about features removed from
>> C++14 to a TS; I have changed them from editorial notes to plain old text.
>> (I don't know what's going to happen with the array extension TS, but it is
>> still an official project with an official number; hopefully something will
>> come of it.)
>>
>>
>> This still needs work in three areas:
>>
>> 1. We need introductory text and rationale for __has_cpp_attribute.
>> (Richard?)
>>
>> 2. We need to approve what we want to do about the LWG issues that Alisdair
>> brought up.
>>
>> 3. We need to make final determinations about shared_mutex.
>>
>> --
>> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee)
>> Intel Corporation Chair, SG10 (C++ SG for feature-testing)
>> clark.nelson_at_[hidden] <mailto:clark.nelson_at_[hidden]> Chair, CPLEX (C SG for parallel language extensions)
>>
>>
>> _______________________________________________
>> Features mailing list
>> Features_at_[hidden] <mailto:Features_at_[hidden]>
>> http://www.open-std.org/mailman/listinfo/features
> I apologize for sending this so late but I thought I had lost some
> notes regarding C++98 and C++11.
> I collected some thoughts on "finishing" these areas if that is
> desired.
>
> Here are some macros to finish-out C++11:
>
> C++11
> -----
> N2439 __cpp_reference_qualifiers 200710 This has library
> usage
>
>
> ref_qualifiers, to match the name of the grammar term?
Works for me.
>
> N2756 __cpp_nsdmi 200809 Hate to spell this out :-(
>
>
> NSDMI is GCC terminology; the standard calls these
> "brace-or-equal-initializers for non-static data members". My
> preferred terminology (with Project Editor hat on) is "default
> initializers". But...
>
> __cpp_aggregate_default_initializers Or this, borrowed from
> CMake?
>
>
> ... we already have __cpp_aggregate_nsdmi, which is ... presumably ...
> what CMake means by this?
>
> If we had a time machine, I'd like __cpp_default_initializers ==
> 200809L here and __cpp_default_initializers == 201304L for N3653. As
> things stand, the most consistent thing is probably '__cpp_nsdmi'.
Ditto. I guess I was feeling wordy when I wrote this :-)
>
> N1986 __cpp_delegating_constructors 200604 Users can migrate
> from initializer functions
> N2540 __cpp_inheriting_constructors 200802 Ditto
> N2930 __cpp_range_based_for_loops 200907
>
>
> Seems a bit wordy. __cpp_range_for ?
Cool.
>
> N2672 __cpp_initializer_lists 200806
>
> Some popular C++ compilers still don't support all these.
> It doeas add a few more macros but it finishes C++11.
> Other compilers may emerge that need to "work their way up"
> through these features.
> I could go either way on this - I know some don't want to clutter
> up compilers with lots of macros.
>
>
> C++98
> -----
> __cpp_exceptions 199711L
>
> __cpp_run_time_type_id 199711L
>
>
> I'd prefer __cpp_rtti
>
That's reasonable. Everyone knows what rtti means.