Subject: [SG10] Minutes from 06-19 teleconference
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2013-06-19 19:11:55
Clark Nelson (3 action items)
Our next teleconference, to respond to comments from WG21 at large, will be
on July 24 -- five weeks from today (not six, as I claimed in the meeting).
Concerning the introductory prose: The too-complicated-and-too-simple example
originally from N3435 was missed; it will be restored.
Especially for language features, macro names should use plural wherever it
makes sense. (Clark has reviewed this for consistency, but standards of
consistency can differ.)
For library features, what immediately follows "__cpp_lib_" should be a name
from the library, wherever it makes sense. (No AI assigned; extra credit to
anyone who steps up to review for this.)
The consensus at this meeting was that macros for language features should
be predefined. Most shops already have their own header for configuration
purposes; it can be modified to bridge short-term gaps.
Just for expediency, to avoid controversy and confusion, in the mid-term
mailing the tables for C++11 features and conditionally-supported constructs
will be replaced by stubs indicating our plans to cover them eventually.
(We should probably add a similar stub concerning exceptions and RTTI from
C++98, to attempt to preserve Benjamin's internals.)
We spent quite a bit of time discussing what to do about new headers. There
was a proposal that macros for new headers should be defined in some existing
header; <cstddef> was suggested. It was also proposed that SG10 should
recommend that implementers provide __has_include (like clang), presumably
later to be added to C++17. We did not discuss whether doing both might be a
(AI Clark to fill in section on __has_include.)
In the discussion of specific macros, a fair amount of time was spent
discussing exactly how many macros are justified, and how to know which ones
are justified. Consensus was that this can be determined only case by case.
Consensus was also that fewer macros doesn't necessarily mean a simpler/
better proposal; associating a new value with an existing macro must also be
evaluated case by case.
A macro for N3323 (tweaks to contextual conversions) was deemed to be
The usefulness of separate macros for N3648 (generalized capture) and N3649
(generic lambdas) was questioned; consensus supported both.
Consensus also supported using different values of a single macro
(__cpp_constexpr) to detect support for N3652 (relaxed constraints on
With respect to N3657 (heterogeneous comparison lookup), the use of the word
"generic", proposed by the authors (after considerable email discussion),
was questioned. Clark will post for SG10 something by way of explanation.
Several other non-controversial name selections/adjustments were made as well.
An updated document is attached. Yellow notes relate to actions required
before the mid-term mailing; STUBS are expected to survive unchanged until
-- 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)
SG10 list run by email@example.com