[SG10] New draft of SD-6

Ed Smith-Rowland 3dw4rd at verizon.net
Tue Sep 30 02:57:10 CEST 2014


On 09/29/2014 03:46 PM, Richard Smith wrote:
> On Sun, Sep 28, 2014 at 5:17 PM, Ed Smith-Rowland <3dw4rd at verizon.net 
> <mailto:3dw4rd at verizon.net>> 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 intel.com  <mailto:clark.nelson at intel.com>   Chair, CPLEX (C SG for parallel language extensions)
>>
>>
>>     _______________________________________________
>>     Features mailing list
>>     Features at isocpp.open-std.org  <mailto:Features at isocpp.open-std.org>
>>     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.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.open-std.org/pipermail/features/attachments/20140929/0cac706c/attachment.html 


More information about the Features mailing list