C++ Logo


Advanced search

Re: [SG10] Minutes from 06-03 teleconference

From: Richard Smith <richard_at_[hidden]>
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

Received on 2013-06-05 01:37:06