Response to “Clarifying the status of feature test macros”

Quotes from P0697R0 appear in boxes. Questions arising from that paper are bold and underlined.

SD-6’s current status as a WG21-authored but not WG21-approved de facto specification is causing confusion in the marketplace. Furthermore, it is still incomplete with missing sections. This paper proposes that WG21 makes a clear decision on whether it wants to turn SD-6 into a completed formal specification of some kind, or else abandon it.

What form does the confusion in the marketplace take?

Certainly WG21 has never approved the details of SD-6. But it is hard to interpret the Kona straw poll:

Should WG21 encourage, but not require, feature-test macros for proposals?

SF	F	N	A	SA
50	13	7	3	2

as not implying approval for the principles of SD-6, given that over twelve times as many people were in favor as were opposed, and twice as many were strongly in favor as were not strongly in favor.

The result is that we have produced SD-6 as the only specification produced by WG21 (ever, to my knowledge) that has never been the subject of a committee technical plenary poll, or been formally approved by national bodies via ISO ballots.

I strongly suspect that no document like SD-6 has ever been produced by any standards group, and for good reason. What SG10 has been trying to do goes well beyond the scope of a standard.

From the perspective of the standard process, there is a quantum jump from one revision to the next, and conformance to a standard is strictly Boolean – lack of conformance in any respect means nonconformance, with no partial credit for partial results.

But that ignores the reality that standard-making is actually a process that takes time, and that implementers and programmers watch that process with interest. SG10 is trying to arrange a portable way for implementers and programmers to maximize the usefulness of their work, taking this reality into account. To do this, it is critical that feature-test macro recommendations be published during the standardization process, as closely as possible to the time it is known that the feature will be in the next standard.

Because all this transcends the world-view of the standard process, I don't see how the goal toward which we are working could be achieved by the kind of process that standards must follow.

The camel’s nose has entered the standard: Part of SD-6 (__has_include) has since been put into the C++ standard as a normative requirement. Some experts and users have expressed that they feel it is odd to support testing for a whole header, but not for individual features.

Does this subjective feeling of oddness represent any actual problem, objectively speaking?

(FWIW, I never intended __has_include to be the spearhead of a massive feature-test invasion into the standard. It's really just an obvious and useful preprocessor feature that has been missing for a long time. I know something like it was proposed to the C committee before; if I recall correctly, at the time it was considered too inventive. But times do change; they seem to be looking favorably at it this year.)

Subgroups have started recommending (and even requiring) that new proposals contain feature test macros as a consideration (and sometimes a condition) of passing subgroup review. However, expectations about this seem to be at least party-unwritten rules.

See the Kona straw poll.

Of course it would be possible for a proposal author to flout the advice of the experts in WG21 and/or one of its working groups, and refuse a request to add a feature-test macro to their proposal.

If someone were to insist on taking that course, whatever group was considering their proposal would have no choice but to decide whether to advance it on its merits, possibly considering the absence of a feature-test macro to be a disadvantage. Then the proposal would either pass or fail.

If the proposal were to pass, then the proposer would have lost his best chance to influence SG10 as to whether the feature should have a macro, or what its name should be if so. And if SG10 is forced to make a decision without input from the proposer or from other experts from another working group, the likelihood of mistakes goes up.

At least some WG21 experts who formerly supported feature test macros now appear to feel the macros are not as useful as was thought.

More information on this point would be very much appreciated. In particular, does “not as useful as was thought” imply not worth doing at all?

Second, the current version of the document (as of this writing, 2016-02-23) still appears incomplete, with “STUBS for sections expected to be filled in later” [emphasis added], including the sections “Conditionally-supported constructs” and “C++98 features.” If we want to keep this document, we should complete it.

SG10 has already decided that those stubs should simply be deleted, but a new revision hasn't been published since that decision was reached.

But FYI, you appear to have missed this little gem from SD-6:

Many of the examples here have been shamelessly and almost brainlessly plagiarized from the cited paper. Assistance with improving examples is solicited.

:-)

WG21 needs to decide whether SD-6 is something officially blessed by the committee that should be turned into something more formal, or should be abandoned, because its halfway-existence is causing confusion in the marketplace, and to some extent within the committee.

I'm afraid that, with no more information than I now have about the nature and consequences of this confusion, I don't yet see why the status quo should be considered an unacceptable alternative.