alx-0014 - Refactor syntax of preprocessing directives

[alejandro-colomar]

Closes: #8249

Cc: @jwakely , @jensmaurer

[alejandro-colomar]

I wasn't able to build the draft PDF locally, so this is untested.

[alejandro-colomar]

@jwakely , @jensmaurer

I recommend reviewing these commits with git-show(1)'s --color-moved, which shows that all of this is moving text around, with no real changes (other than the additions of *-directive syntax entries, of course).

Is it okay like this? Or do you prefer it squashed in one commit?

(I wish github had this --color-moved in the WebUI. Actually, I wish I wasn't using github. :) )

[alejandro-colomar]

Ping. :)

[AlisdairM]

As we are in the ballot resolution period for the C++26 standard, I would not be waiting too eagerly for a change of this scale to be reviewed in the next six months or so. I might happen, as we want to produce the highest quality standard that we can, but we also have significant work to resolve NB concerns and publish the completed standard that clearly have our undivided attention until then.

[alejandro-colomar]

As we are in the ballot resolution period for the C++26 standard, I would not be waiting too eagerly for a change of this scale to be reviewed in the next six months or so. I might happen, as we want to produce the highest quality standard that we can, but we also have significant work to resolve NB concerns and publish the completed standard that clearly have our undivided attention until then.

Thanks! That's useful info to me. :)

Cheers,
Alex

[tkoeppe]

Also, even though grammar productions are ultimately not observable, I'd hesitate to call such a change editorial, since the wording groups made a deliberate choice in the manner of presentation. I would prefer if such a proposed change were delivered as an (editorial) paper addressed at the relevant wording group (CWG in this case).

[alejandro-colomar]

@tkoeppe

Also, even though grammar productions are ultimately not observable, I'd hesitate to call such a change editorial, since the wording groups made a deliberate choice in the manner of presentation.

Why do you claim "the wording groups" made a deliberate choice in the manner of presentation?

This wording has been kept essentially intact since ANSI C89.

The only choice that has been made ever since, was when adding modules; the only significant change to the directives since ANSI C89.

Guess what? They added modules in the same manner I'm proposing now. If you notice, the only thing I haven't moved is the syntax for modules, precisely because it's organized exactly as I'm proposing for the rest of the directives.

So, the only actual deliberate choice that has been ever made regarding this in the last 35 years has been in the same direction of my proposal.

See the current syntax for pp-import, FWIW.

I would prefer if such a proposed change were delivered as an (editorial) paper addressed at the relevant wording group (CWG in this case).

You have my proposal for wg14, which is written in a paper. With minor modifications, you can get it to apply to C++. In fact, you can just skip the "proposed wording", as you have here the actual diff, and read only the rationale, which applies entirely.

I'll paste the rationale here (I'll paste the one from the updated paper I'll present soon):

Rationale
        Editorial change.  This moves text around for better
        organization and readability.  No semantic changes.  This makes
        it so that any future proposals to the preprocessor will be
        easier to apply.

        The proposal is split in subsections, separated by '---', for
        better readability.

        This proposal applies as is to the C++ latest draft, N5014, only
        changing section numbers and their titles.

        This change has prior art in C++, as they've done the same exact
        thing with their pp-import directive.  I guess they haven't done
        it with the other directives for compatibility with us, so let's
        help them and do it everywhere.

    Interaction with other proposals
        This blocks alx-0003 ("Add directives #def and #enddef")
        This blocks alx-0013 ("Prohibit non-directives (other than ID directives)").

Here's the wg14 paper:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3632.txt

[jensmaurer]

Why do you claim "the wording groups" made a deliberate choice in the manner of presentation?

A choice made four decades ago can still qualify as a deliberate choice, even if we prefer to phrase things differently now.

[alejandro-colomar]

Why do you claim "the wording groups" made a deliberate choice in the manner of presentation?

A choice made four decades ago can still qualify as a deliberate choice, even if we prefer to phrase things differently now.

But WG21 has already decided to not follow that anymore, when modules were added. That makes it an editorial change to align the rest of the directives with modules. I don't think this needs to waste much time from subgroups.

15.1 (Preprocessing directives :: Preamble) refers to pp-import

control-line :
  # include pp-tokens new-line
  pp-import
  # define identifier replacement-list new-line
  # define identifier lparen identifier-listopt ) replacement-list new-line
  # define identifier lparen ... ) replacement-list new-line
  # define identifier lparen identifier-list , ... ) replacement-list new-line
  # undef identifier new-line
  # line pp-tokens new-line
  # error pp-tokensopt new-line
  # warning pp-tokensopt new-line
  # pragma pp-tokensopt new-line
  # new-line

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf#section.15.1

which is defined in 15.5 (Header unit importation)

pp-import :
  exportopt import header-name pp-tokensopt ; new-line
  exportopt import header-name-tokens pp-tokensopt ; new-line
  exportopt import pp-tokens ; new-line

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/n4950.pdf#section.15.5

That's how the syntax for all directives should be defined.

[tkoeppe]

All the same, CWG is used to the current grammar, and I would not want to change it without their awareness. It seems that Jens has already said as much in #8249 (comment).

But perhaps we can just get CWG to take a look at this pull request to get us started. @jensmaurer Could we slot this in somewhere?