Date: Mon, 3 Jun 2013 21:54:52 +0000
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.
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 (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.
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)
Received on 2013-06-03 23:55:18