On Tue, 6 Oct 2026 at 23:03, Hubert Tong <hubert.reinterpretcast_at_[hidden]>
wrote:

> 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?
>

Sorry, I should have said basic latin 1 here (or to be more clear that I
meant the ASCII character set, not the encoding) . std::format for example
assumes the existence of braces.


>
> - 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?
>

If we can agree that the use cases for digraph/trigraphs can be limited to
a few pragmas or a narrow set of features, I'd be happy to support whatever
compiler extension would ease the pain.
Making ??=pragma a magic keyword-like thing (or whatever design we can come
up with) is perfectly fine by me (with the caveat that I do not speak for
the clang community).
I.e, i think most of the unhappiness with these things come from the fact
they can appear anywhere, so if we reduce the scope to what we actually use
them for, we might satisfy everyone?


>
>
>> - 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.
>