Removing Digraphs

Revision history

0.1. R0 May 2026

Original version of the paper.

1. Introduction

Digraphs are a complicated solution to a very old problem, that cause more problems than they solve in a modern environment. Digraphs also severely limit the design space of C++, although as we have seen with [P2996] we are already fine with special-casing our way out of this pickle.

This however introduces an interesting problem: If you need to use a source encoding that requires use of digraphs, you cannot use all of C++26

directly.

Since we are most likely going to continue seeing similar problems, this paper proposes to remove digraphs from the language entirely.

2. Design Space

As mentioned before, digraphs severely limit the design space of C++. This isn't an entirely new insight, in fact we've ran into issues because of digraphs already and will most likely continue to run into new issues because of digraphs.

This leads to a fragmented language - some parts you can write if you need to use digraphs, some you don't. At the same time we're accumulating workarounds (like [CWG1104]), which lead to an excessively complex language.

2.1. Splicers

Splicers from [P2996] were accepted for C++26 with the proposed syntax [: expr :]. However, we are not allowed to use digraphs to spell this as <:: expr ::>.

While that seems to be in direct contradiction of the guarantees we're given in [lex.digraph] paragraph 2

In all respects of the language, each alternative token behaves the same, respectively, as its primary token, except for its spelling.

it actually isn't. The tokens [: and :] are distinct preprocessing tokens rather than being composed from [ and : (or : and ] respectively). Therefore it doesn't matter whether <: is a valid alternative spelling for [ - the splicer syntax does not contain [ tokens.

Unfortunately that doesn't exactly help if your source encoding does not have angle brackets. In such cases you cannot use this language feature directly - you'd have to find some workaround (such as inventing some arbitrary replacement sequence that is expanded to [: after transcoding).

3. Interpolated string literals

The design problems stemming from digraphs do not end there. In some of the recent discussions around string interpolation ([P3412], [P3951]) some interesting code was brought up. Consider the following:

In an interpolated string literal, the interpolated expression field is wrapped in curly braces. To parse an interpolated string literal you must therefore switch between regular string literal parsing and expression parsing as soon as you see a field introducer ({).

However, once you parse the interpolated expression things get a little strange. %> is an alternative spelling of }. We haven't yet returned back to literal parsing, so this would yield the correct token. So, should we be able to signify the end of the interpolation field with %>?

Since allowing anything but literal } to terminate a interpolation field seems extremely surprising and will most likely not match user expectations, we are noce again looking to disallow digraphs in this context.

Unfortunately that also means that we are once again looking to introduce a feature that you cannot directly use if your source encoding requires the use of the corresponding digraphs.

4. History

Digraphs are a very rarely used C++ feature. GCC goes as far as calling it "obscure" in their documentation:

Apparently in the 1990s some computer systems had trouble inputting these characters, or trouble displaying them. These digraphs almost never appear in C programs nowadays, but we mention them for completeness.

What the GCC documentation refers to here is systems that require the source encoding to be something that does not have the characters <, >, [, ], { or }. In such cases, the corresponding digraphs are required to write those characters in source code.

Such encodings are rather uncommon nowadays, but they do exist.

Historically digraphs were introduced because of [ISO 646], which includes several national variants that do not have the angle brackets or curly braces. For example, the [ISO-IR-021] (also known as DIN 66003) variant used in Germany replaces [ with Ä, ] with Ü, { with ä and } with ü.

Interestingly, [ISO-IR-027] even lacks :, making two of the digraphs unusable. While it's based on ISO 646, it is not a true variant however.

So, how did we get here?

5. Usage Analysis

This raises an obvious question: Are people still using digraphs? Are they targeting somewhat modern C++ versions?

A GitHub code search can unfortunately not answer this question for us, since a lot of use might be in code that isn't publicly available. However, it helps getting a rough idea of the situation and how people use digraphs.

Surprisingly, we can actually find quite a lot of code that uses digraphs. For example %:include is included in 850 files!

However, if you take a closer look at those results, you'll quickly notice that aside from a bunch of false positives most of them fall into one of three categories:

1. Compiler test code and other lexer test code
2. Demo code, examples and student assignments
3. Inconsistent use of digraphs and the tokens they replace, likely for obfuscation purposes

Note how this list is missing "actual production code that uses digraphs for anything other than tests".

For the other digraphs the situation is similar. %:%: yields 216 results, most of which are false positives and/or lexer code. %:if yields 22 results, all of which are university assignments, inconsistent or false positives.

For the digraphs <:, :>, <% and %> a code search yields a lot more results, but they seem to be almost exclusively false positives - usually because they appear in string literals or comments. Furthermore, <: yields especially bad results due to qualified template arguments being spelled as templ<::arg> (without space after <). Due to platform rate limits further usage analysis for those does not seem feasible.

6. Compatibility

In C++14 we removed support for trigraphs. Since this has been quite a while back now, it is fair to assume that mitigations for users that required use of trigraphs but wanted to target anything beyond C++11 are in place.

While more complex approaches (such as filesystem-level transcoding) are possible, at the time of writing almost all compilers still support trigraphs as an extension. For instance:

• GCC has -trigraphs
• Clang has -ftrigraphs
• MSVC has /Zc:trigraphs
• EDG has --trigraphs

While the situation around digraphs is arguably a little different and might require extra preprocessing to use of all language features, mitigations will likely look similar to the ones required for trigraphs.

Some compilers already support disabling digraph support altogether. For instance:

• Clang has -fno-digraphs
• EDG has --no_alternative_tokens
• MSVC's documentation of compiler warning C4628 and C4629 suggests using digraphs is not supported with /Ze and will cause a warning with /Za, however Compiler Explorer does not verify that

7. Wording

Make the following changes to the C++ Working Draft. All wording is relative to [N5032], the latest draft at the time of writing.

Lexical conventions [lex]

Preprocessing tokens [lex.pptoken]

Operators and punctuators [lex.operators]

Modify as indicated.

Alternative tokens [lex.digraphalt]

Rename to [lex.alt] and update all references accordingly.

Modify Table 3

Remove footnote 10

Preprocessing directives [cpp]

Argument substitution [cpp.subst]

Modify Example 1 as indicated.

Annex C (informative) [diff]

C++ and ISO C++ 2026 [diff.cpp26]

[lex] lexical conventions [diff.cpp26.lex]

Add new entry

8. Acknowledgements

Thanks to Jan Schultke for the markup language and document generator used for this paper.

9. References