Subject: Re: [SG10] __has_[cpp_]attribute
From: Nelson, Clark (clark.nelson_at_[hidden])
Date: 2014-06-18 12:09:21
This was discussed in EWG this afternoon.
One of the principal objections to this idea has been the complications
involved in implementing it with a separate preprocessor. But no one could
think of any popular C++ implementation that actually uses a separate
preprocessor. It was also pointed out that we've been making more and more
changes that mean that a standard preprocessor for C can't be used for C++,
including raw string literals in C++11 and apostrophe as a digit separator
in C++14. (And for that matter bool in C++98.) Using a separate preprocessor
is just getting harder and less likely. It was also pointed out that, if the
preprocessor is integrated with the parser, a single table of attributes can
be used for both parsing and feature-testing.
Tom Plum's idea of using #undef as a workaround for a case where an
implementation of a feature is too buggy to use was also mentioned. But it
was pointed out that SD-6 doesn't promise that our recommended predefined
macros can be #undef-ed, and EDG's implementation, at least, doesn't allow
them to be. In any event, there's really no way any specification can place
additional constraints on an implementation that doesn't conform to it.
I didn't bother to record the numbers of the straw poll. Even Tom changed
his mind and voted for __has_cpp_attribute, and no one voted against it. (If
I had bothered to raise my hand, it would have been for "neutral".)
So it looks like we'll be adding __has_cpp_attribute to our recommendations.
-- Clark Nelson Vice chair, PL22.16 (ANSI C++ standard committee) Intel Corporation Chair, SG10 (C++ SG for feature-testing) clark.nelson_at_[hidden] Chair, CPLEX (C SG for parallel language extensions)
SG10 list run by firstname.lastname@example.org