On Tuesday, September 29th, 2026 at 10:31 AM, Jens Maurer via SG16 <sg16_at_[hidden]> wrote:

>
>
> On 9/28/26 23:01, Tom Honermann via SG16 wrote:
> > I don't think trigraphs can ever be a conforming extension. The following example has well-defined behavior in ISO C++, but behaves differently when trigraphs are enabled. https://godbolt.org/z/o3xznsrGY.
> >
> > #include <cstdio>
> > int main() {
> > std::printf("It's like magic: '??!'\n");
> > }
>
> The model is that trigraphs are mapped in phase 1 (which is implementation-defined),
> and the implementation is simply considered to use a (rather strange) source file
> encoding. Which is conforming.
>
> Whether that kind of allowance jeopardizes the portability promises of C++
> is another question.

I will argue that it does not. Transferring source code to and from this system needs an encoding transformation, and whether that encoding transformation is just replacing byte values with different byte values, or substituting ??/ for \ and vice versa is an implementation detail.

As long as the system can encode all required symbols in some way, you can convert code to and from that system.

I would strongly recommend against *actually* using any such system, but about as much as I'd recommend against using anything but UTF8 normally. There are only downsides and extra steps. Ideally somebody would make an open source application that automatically de-digraphs or de-trigraphs source code, so that users that do have code that uses it can use that once - akin to fromdos - to get rid of it and move to modern systems that no longer need such workarounds.