﻿<!DOCTYPE html>
<html lang="en" xmlns="http://www.w3.org/1999/xhtml">
<head>
  <meta charset="utf-8" />
  <title>Response to “Clarifying the status of feature test macros”</title>
  <style type="text/css">
    blockquote.p {
      border-style: solid;
      border-width: thin;
      padding-left: 1em;
      padding-right: 1em;
    }

    .q {
      font-weight: bold;
      text-decoration: underline;
    }
  </style>
</head>
<body>
  <table border="1">
    <tbody>
      <tr>
	<th>Doc. no:</th>
	<td>P0723R0</td>
      </tr>
      <tr>
	<th>Date:</th>
	<td>2017-06-22</td>
      </tr>
      <tr>
	<th>Reply to:</th>
	<td><a href="mailto:clark.nelson@intel.com">Clark Nelson</a></td>
	<td><a href="mailto:jhs@edg.com">John Spicer</a></td>
      </tr>
    </tbody>
  </table>
  <h1>Response to &ldquo;Clarifying the status of feature test macros&rdquo;</h1>
  <p>
    Quotes from <a href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0697r0.pdf">P0697R0</a>
    appear in boxes.
    Questions arising from that paper are bold and underlined.
  </p>
  <blockquote class="p">
    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.
  </blockquote>
  <p class="q">
    What form does the confusion in the marketplace take?
  </p>
  <p>
    Certainly WG21 has never approved the <strong>details</strong> of SD-6.
    But it is hard to interpret the Kona straw poll:
  </p>
  <blockquote style="border-style: none">
    <p>
      Should WG21 encourage, but not require, feature-test macros for proposals?
    </p>
    <table border="1">
      <thead>
	<tr>
	  <th>SF</th>
	  <th>F</th>
	  <th>N</th>
	  <th>A</th>
	  <th>SA</th>
	</tr>
      </thead>
      <tbody>
	<tr>
	  <td>50</td>
	  <td>13</td>
	  <td>7</td>
	  <td>3</td>
	  <td>2</td>
	</tr>
      </tbody>
    </table>
  </blockquote>
  <p>
    as <strong>not</strong> implying approval
    for the <strong>principles</strong> 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.
  </p>
  <blockquote class="p">
    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.
  </blockquote>
  <p>
    I strongly suspect that no document like SD-6
    has ever been produced by <strong>any</strong> standards group,
    and for good reason.
    What SG10 has been trying to do goes well beyond the scope of a standard.
  </p>
  <p>
    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 &ndash;
    lack of conformance in any respect means nonconformance,
    with no partial credit for partial results.
  </p>
  <p>
    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.
  </p>
  <p>
    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.
  </p>
  <blockquote class="p">
    <em>The camel’s nose has entered the standard:</em>
    Part of SD-6 (<code>__has_include</code>)
    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.
  </blockquote>
  <p class="q">
    Does this subjective feeling of oddness represent any actual problem,
    objectively speaking?
  </p>
  <p>
    (FWIW, I never intended <code>__has_include</code> 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.)
  </p>
  <blockquote class="p">
    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.
  </blockquote>
  <p>See the Kona straw poll.</p>
  <p>
    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.
  </p>
  <p>
    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.
  </p>
  <p>
    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.
  </p>
  <blockquote class="p">
    At least some WG21 experts
    who formerly supported feature test macros
    now appear to feel the macros are not as useful as was thought.
  </blockquote>
  <p class="q">
    More information on this point would be very much appreciated.
    In particular, does &ldquo;not as useful as was thought&rdquo; imply
    not worth doing at all?
  </p>
  <blockquote class="p">
    Second, the current version of the document
    (as of this writing, 2016-02-23) still appears incomplete,
    with “STUBS for sections <em>expected to be filled in later</em>”
    [emphasis added], including the sections
    “Conditionally-supported constructs” and “C++98 features.”
    If we want to keep this document, we should complete it.
  </blockquote>
  <p>
    SG10 has already decided that those stubs should simply be deleted,
    but a new revision hasn't been published since that decision was reached.
  </p>
  <p>But FYI, you appear to have missed this little gem from SD-6:</p>
  <blockquote>
    Many of the examples here
    have been shamelessly and almost brainlessly plagiarized
    from the cited paper.
    Assistance with improving examples is solicited.
  </blockquote>
  <p>:-)</p>
  <blockquote class="p">
    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. 
  </blockquote>
  <p>
    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.
  </p>
</body>
</html>
