I remember the distinction between trigraphs and digraphs now.

Trigraphs were processed at a per-character level, essentially a form of character
encoding in source. When trigraphs were removed, IBM are able to continue
honoring trigraphs with their original meaning by making them part of the phase 1
source-to-basic-character-set mapping.

Digraphs work at the token level, so are *not* appropriate for handling as part of
the character mapping in phase 1. This shows up in things like string literals. Note
that the old rules for backing out trigraph expansion in raw string literals no longer
easily apply in the IBM case, but they seemed ready to accept that as long that they
can portably pragma the code page. Hubert might well correct me on “accept” though ;)

If this has already been stated, sorry for the noise, but I wanted to be sure that the
difference was called out clearly, as it could directly impact the motivation, or the way
way wet describe the motivation.

AlisdairM

> On Oct 6, 2026, at 5:03 PM, Hubert Tong via SG16 <sg16_at_[hidden]> wrote:
>
> On Wed, Sep 30, 2026 at 5:25 AM Corentin Jabot via SG16 <sg16_at_[hidden] <mailto: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 <mailto: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.
> --
> SG16 mailing list
> SG16_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/sg16
> Searchable archives: http://lists.isocpp.org/sg16/2026/10/index.php