Date: Tue, 4 Jun 2013 16:37:04 -0700
On Mon, Jun 3, 2013 at 2:54 PM, Nelson, Clark <clark.nelson_at_[hidden]>wrote:
> Attendees:
>
> Clark Nelson (2 action items)
> John Spicer
> Tom Plum (1 action item)
> Walter Brown
> Ben Kosnik (will produce a survey paper by the next meeting)
>
>
> Decisions reached:
>
> We will have another teleconference, in the same time slot (17:00Z), on
> Wednesday, June 19.
>
> When the document is first published for WG21 in general, the fact will be
> announced on all major reflectors, and feedback will be urgently solicited,
> to try to resolve controversy before we get to the Chicago meeting.
>
> For the time being, at least, we will stick with only one document. To it
> need to be added:
>
> * Explanation and rationale for the approach and scope
> * Macros in the same style for features of C++11, starting with Tom's list
> * Macros for conditionally-supported features of C++11
>
> Clark will revise the proposal. (AI for Clark)
>
> We considered a distinction like that of clang's __has_feature vs.
> __has_extension, but consensus was there is not adequate justification.
>
I don't think this addresses my question on this front, which was: which of
those two behaviors do the feature-test macros provide? Was that question
resolved by the discussion?
> There was considerable discussion of whether macros, especially for
> language features and library headers, should be specified as predefined or
> defined in some new header. This represents a bootstrapping issue: how to
> know whether the new header is available? In the end, without either a
> specific proposal or consensus for a change, we decided to leave things as
> is (i.e. predefined); Tom offered to propose an alternative for future
> consideration. (AI for Tom)
>
> By a slim margin, the consensus was that, for example, the C++14
> extensions to constexpr and lambdas should be identified by new macro
> names, and not just higher macro values, to simplify testing code. In
> general, an increased macro value should be associated with a relatively
> minor/subtle tweak to a feature, such as happened to lambdas during the
> C++11 process (and in very few other cases). It was also decided that the
> value of a macro should identify the month of the WG21 vote to adopt the
> feature.
>
> Specific names discussed: __cpp_new_merging (re N3664) is not needed.
> N3638 should be represented by __cpp_decltype_auto as well as
> __cpp_return_type_deduction.
>
> There was general support for replacing __cpp_relaxed_constexpr with
> __cpp_generalized_constexpr, and general dissatisfaction with
> __cpp_lib_robust_sequences, with no alternative proposed. There was also
> discussion of the importance of the stability of the macro names proposed
> -- and consequently, the importance that meaningful names be proposed up
> front. In the future, the name should ideally be proposed and adopted as
> part of the feature proposal itself. For the macros being proposed at this
> time, Clark will contact the authors of the papers for feedback on the
> names before first publication as a WG21 paper. (AI for Clark)
>
> --
> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee)
> Intel Corporation Chair, SG10 (WG21 study group for C++
> feature-testing)
> clark.nelson_at_[hidden] Chair, CPLEX (WG14 study group for C parallel
> language extensions)
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
> Attendees:
>
> Clark Nelson (2 action items)
> John Spicer
> Tom Plum (1 action item)
> Walter Brown
> Ben Kosnik (will produce a survey paper by the next meeting)
>
>
> Decisions reached:
>
> We will have another teleconference, in the same time slot (17:00Z), on
> Wednesday, June 19.
>
> When the document is first published for WG21 in general, the fact will be
> announced on all major reflectors, and feedback will be urgently solicited,
> to try to resolve controversy before we get to the Chicago meeting.
>
> For the time being, at least, we will stick with only one document. To it
> need to be added:
>
> * Explanation and rationale for the approach and scope
> * Macros in the same style for features of C++11, starting with Tom's list
> * Macros for conditionally-supported features of C++11
>
> Clark will revise the proposal. (AI for Clark)
>
> We considered a distinction like that of clang's __has_feature vs.
> __has_extension, but consensus was there is not adequate justification.
>
I don't think this addresses my question on this front, which was: which of
those two behaviors do the feature-test macros provide? Was that question
resolved by the discussion?
> There was considerable discussion of whether macros, especially for
> language features and library headers, should be specified as predefined or
> defined in some new header. This represents a bootstrapping issue: how to
> know whether the new header is available? In the end, without either a
> specific proposal or consensus for a change, we decided to leave things as
> is (i.e. predefined); Tom offered to propose an alternative for future
> consideration. (AI for Tom)
>
> By a slim margin, the consensus was that, for example, the C++14
> extensions to constexpr and lambdas should be identified by new macro
> names, and not just higher macro values, to simplify testing code. In
> general, an increased macro value should be associated with a relatively
> minor/subtle tweak to a feature, such as happened to lambdas during the
> C++11 process (and in very few other cases). It was also decided that the
> value of a macro should identify the month of the WG21 vote to adopt the
> feature.
>
> Specific names discussed: __cpp_new_merging (re N3664) is not needed.
> N3638 should be represented by __cpp_decltype_auto as well as
> __cpp_return_type_deduction.
>
> There was general support for replacing __cpp_relaxed_constexpr with
> __cpp_generalized_constexpr, and general dissatisfaction with
> __cpp_lib_robust_sequences, with no alternative proposed. There was also
> discussion of the importance of the stability of the macro names proposed
> -- and consequently, the importance that meaningful names be proposed up
> front. In the future, the name should ideally be proposed and adopted as
> part of the feature proposal itself. For the macros being proposed at this
> time, Clark will contact the authors of the papers for feedback on the
> names before first publication as a WG21 paper. (AI for Clark)
>
> --
> Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee)
> Intel Corporation Chair, SG10 (WG21 study group for C++
> feature-testing)
> clark.nelson_at_[hidden] Chair, CPLEX (WG14 study group for C parallel
> language extensions)
>
> _______________________________________________
> Features mailing list
> Features_at_[hidden]
> http://www.open-std.org/mailman/listinfo/features
>
Received on 2013-06-05 01:37:06