On Wed, Sep 30, 2026 at 5:25 AM Corentin Jabot via SG16 <
sg16_at_[hidden]> wrote:

>
>
> I'm saying the phase 1 wording gives enough flexibility to perform or not
> trigraphs replacement, and that an implementation can choose to do that
> replacement or not in string, raw strings etc.
>
>
> To get us back on topic, I'm arguing that we should do what the paper is
> proposing.
>

Provided that there is some clear agreement on how the ??=pragma use case
could be handled in the long term within Clang (or more directly blessed by
the standard), I am not against the removal of digraphs.
On that front, I think that a variation of the paper's 7.2, "Partially
reintroduce trigraphs", would work: namely changing the directive syntax to
accept ??= in place of #.


> The status quo is that
>
> - EBCDIC encodings can use trigraphs as a conforming extension
>

Yes, but depending on the form of the extension, it can harm the
portability of C++ programs. For example, by replacing trigraphs in non-raw
strings. It does seem that just leaving trigraphs on is working at this
time though, but I am not comfortable with relying on that to hold.


> - Encodings for which digraphs were standardized are no longer in use -
> they were obsoleted by the time digraphs were standardized.
>

This ignores Tom's point that digraphs can be used to write C/C++ such that
an encoded file could be interpreted using multiple encodings without
change in meaning. For example, by using only characters that encode the
same way between the various encodings of interest. I personally make use
of this to write tests having to do with different input encodings.

  - The standard librarie prevent the existence of a conforming
> implementation that would not support ascii-like encoded source files
>

What are your supporting points for this statement? Perhaps you mean that
such libraries introduce friction for cases where digraph usage would be
required?

  - There is a basic expectation that code is written in an ASCII superset.
>

Certainly not in the sense of ASCII-compatible as defined by P3688R6.


> I imagine IBM might want to write code in e.g, rust, and I doubt rust has
> any appetite for digraphs.
>

Rust has no appetite for EBCDIC source files :)


> I cannot imagine anyone being keen on spreading digraphs all over source
> code.
>

Yes, I don't think people sprinkle digraphs all over source code either.

  - We know that ??=pragma is the one important use case. i.e we should
> assume new code in an EBCDIC environment ought to be written in IBM47 and
> if the compiler assume another encoding, switching seems like a reasonable
> feature, which leaves us to ponder
> - is _Pragma a reasonable substitute
>

No, because the headers need to work for older language levels and legacy
compilers. Also, the pragma in question takes an argument in double quotes,
so we would need ??/ inside the string argument of _Pragma.
@Matthias Wippich <mfwippich_at_[hidden]>: Please note the above as your
paper implies that _Pragma is suitable.


> - can an implementation just treat `??=pragma` as a magic marker as a
> conforming extension - i don't think anything needs standardizing
>

How happy would the Clang maintainers be with doing that?


> - Given that to this day, %:pragma is presumably not something IBM
> uses, why should we suddenly try to preserve that use case?
>

On principle? The committee removed trigraphs claiming that digraphs exist
as a migration path. That said, I think solving ??=pragma is perfectly fine.