Removing Digraphs

Revision history

0.1. R1 October 2026

• Redid iconv analysis as there were some issues with deduplication of encodings in the previous version
• Added released standards and a reference to N033 to the timeline
• Clarified _Pragma usability and other alternatives

0.2. R0 September 2026

Original version of the paper.

1. Introduction

Digraphs are a complicated solution to a very old problem, which 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 leads to a rather unfortunate situation. If you need to use a source encoding that requires use of digraphs, you cannot use all of C++26 directly, resulting in a fragmented and needlessly complex language. Some parts you can use if you require certain digraphs, some you don't.

Since we are most likely going to continue seeing similar problems, this paper proposes to remove the digraphs <%, %>, <:, :>, %: and %:%: from the language entirely. This does not affect the alternative keyword tokens (and, or, etc.).

2. History

The GCC documentation notes:

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 this refers to 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 square 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 ü.

Keld Simonsen pointed out this problem with some ISO 646 variants including the Danish [ISO-646-DK] in a 1984 usenet post. To address this issue, he suggested the following digraphs as a solution ([Simonsen, 1984]):

(. → {

). → }

(* → [

)* → ]

!. → |

!* → \

Even then Martin Minow argued against such a solution, as it was a vanishing problem even at the time.

To quote [Minow, 1984]:

There isn't any really good solution -- it is highly unlikely that the C standardization committee will remove these characters from the language. While most of them can be replaced by suitable #defines, several cannot, notably backslash. The only short-term solution would be for the parties affected to write NRC-specific pre-processors.

In the long term, however, the problem will go away as people move to an 8-bit character set such as Dec-Multinational or the pending ISO standard that is almost identical to it.

That "pending ISO standard" Minow mentions later became [ISO/IEC 8859]. The relevant part of ISO/IEC 8859 for the Danish language is ISO/IEC 8859-1, which was first published in March 1985 as [ECMA-94].

ECMA-94 fully solves the described issue by using the 8th bit in an 8-bit byte to allow for another 96 printable characters, which includes everything that was potentially missing in some ISO 646 variants.

Interestingly, [ISO-IR-027] even lacks :, making four of the digraphs we eventually ended up with unusable. While it is explicitly based on ISO 646, ISO-IR-027 is not a true variant - some of the added letters are mapped to code points which are invariant in ISO 646. However, this shows that even for its original purpose, digraphs are more of a band-aid than a real solution.

2.1. Timeline

So, how did we get here? Unfortunately not a lot of documents from the early days survived. However, the publicly available X3J11, X3J16, WG14 and WG21 documents allow reconstructing roughly this timeline (please reach out if you have corrections or additional information!):

3. Design Space

3.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 square 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 [: during or after transcoding).

3.2. Interpolated string literals

The design problems stemming from digraphs do not end there. In some of the recent discussions around the proposed string interpolation feature ([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 once again looking for a workaround because of digraphs.

To make matters worse, there is another ambiguity. Consider an interpolated literal:

In this example, is :> the digraph for ] or is it the start of the format specifiers of that field? In a non-interpolated format literal, "{:>5}" would be a valid format specifier.

4. Affected encodings

A common way to support arbitrary source encodings is by normalizing the source code through iconv. Therefore, we are typically limited by what iconv supports. Note that iconv also supports several translation character sets that are irrelevant for our purposes. The codec names in this chapter are the primary/canonical names used by iconv rather than necessarily actual codec names.

To figure out whether a particular encoding needs digraphs, we can check whether iconv fails when trying to convert the characters #, [, ], { or } to that encoding. If it does, then that encoding requires digraphs.

In a similar fashion, other characters that have meaning in C++ can be checked. For example, if an encoding does not support :, several digraphs are not usable either. As mentioned before, one such encoding is LATIN-GREEK-1 ([ISO-IR-027]).

On a somewhat recent Arch Linux system, this gives us the following support matrix: View on Google Sheets

Out of 279 considered encodings, 200 can encode the everything in the basic character set. However, 16 cannot even encode at least one character in the ranges a-z, A-Z or 0-9. These are mostly replacement character sets and special purpose encodings (e.g. for Braille or OCR purposes) and are therefore disregarded for the purposes of this document.

Out of the remaining 263 considered encodings, the following 49 encodings lack at least one character for which we have a digraph:

• ISO646-CA
• ISO646-CA2
• ISO646-CU
• ISO646-DE
• ISO646-DK
• ISO646-ES
• ISO646-ES2
• ISO646-FI
• ISO646-FR
• ISO646-FR1
• ISO646-GB
• ISO646-HU
• ISO646-IT
• ISO646-JP-OCR-B
• ISO646-NO2
• ISO646-NO
• ISO646-PT
• ISO646-PT2
• ISO646-SE2
• ISO646-YU
• EBCDIC-AT-DE
• EBCDIC-AT-DE-A
• EBCDIC-CA-FR
• EBCDIC-DK-NO
• EBCDIC-DK-NO-A
• EBCDIC-ES-A
• EBCDIC-ES
• EBCDIC-ES-S
• EBCDIC-FI-SE
• EBCDIC-FI-SE-A
• EBCDIC-FR
• EBCDIC-IS-FRISS
• EBCDIC-IT
• EBCDIC-UK
• EBCDIC-US
• EBCDIC-PT
• IBM274
• IBM275
• IBM281
• IBM420
• IBM423
• IBM880
• IBM4517
• IBM16804
• NATS-DANO
• NATS-SEFI
• Latin-greek-1
• INIS
• T.61-8bit

While these are not the only encodings that cannot represent \ directly, the following 40 encodings out of those 49 also cannot represent \ directly:

• ISO646-CA
• ISO646-CA2
• ISO646-CU
• ISO646-DE
• ISO646-DK
• ISO646-ES
• ISO646-ES2
• ISO646-FI
• ISO646-FR
• ISO646-FR1
• ISO646-HU
• ISO646-IT
• ISO646-JP-OCR-B
• ISO646-NO2
• ISO646-NO
• ISO646-PT
• ISO646-PT2
• ISO646-SE2
• ISO646-YU
• EBCDIC-AT-DE
• EBCDIC-CA-FR
• EBCDIC-DK-NO-A
• EBCDIC-ES-A
• EBCDIC-FI-SE
• EBCDIC-FI-SE-A
• EBCDIC-FR
• EBCDIC-IS-FRISS
• EBCDIC-IT
• EBCDIC-PT
• IBM274
• IBM281
• IBM420
• IBM423
• IBM4517
• IBM16804
• NATS-DANO
• NATS-SEFI
• Latin-greek-1
• INIS
• T.61-8bit

For those, digraphs help but do not provide a complete solution either.

We can narrow that list down even further. The most interesting digraph is %:, since it can be used to spell #pragma. Some compilers already have pragmas to specify the source encoding - for example, the IBM z/OS XL compilers support #pragma filetag (documentation) for this purpose.

If we only have to retain a digraph for #, this narrows the 49 plausible encodings down to the following 22:

• EBCDIC-AT-DE-A
• EBCDIC-DK-NO-A
• EBCDIC-ES
• EBCDIC-ES-A
• EBCDIC-ES-S
• EBCDIC-FI-SE
• EBCDIC-FI-SE-A
• EBCDIC-FR
• EBCDIC-IT
• EBCDIC-PT
• ISO646-ES
• ISO646-FR
• ISO646-FR1
• ISO646-GB
• ISO646-IT
• ISO646-NO2
• IBM275
• IBM423
• IBM4517
• NATS-DANO
• Latin-greek-1
• INIS

Since some compilers support pragmas such as #pragma filetag("..."), these encodings are especially interesting. For these encodings, digraphs allow us to write code in an encoding-agnostic way by using %:pragma filetag("...") instead of #pragma filetag("..."). This is especially useful for shared headers.

Out of the 49 plausible encodings, only 8 have replacements for all characters that currently have meaning in C++. This includes the alternative operators and, or and so on.

• ISO646-GB
• IBM275
• IBM880
• EBCDIC-UK
• EBCDIC-US
• EBCDIC-ES
• EBCDIC-ES-S
• EBCDIC-DK-NO

While this isn't a huge list, it proves the point that there are still encodings that require digraphs.

However, the question remains whether there is any actual use of any of these in practice. Fortunately those are all rather obscure encodings by today's standards.

5. Usage Analysis

So, 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 exercises
3. Inconsistent use of digraphs and the tokens they replace, possibly 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 promising %:pragma we get 107 results, most if not all of which are inconsistent. For %:pragma filetag we get 0 results (even for the trigraph spelling we at least get 106 results).

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

6. Compatibility

At the time of writing almost all major compilers still support trigraphs as an extension. For instance:

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

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

• Clang has -fno-digraphs
• EDG has --no_alternative_tokens (which also disables the alternative operators and, or etc.)
• 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. Alternatives to full digraph removal

As mentioned before, compilers that have pragmas such as #pragma filetag("encoding") only really need some way of spelling that.

In [WG14/N3116] Rajan Bhakta confirms this:

Theoretically the # is the only one we need, to engage the pragma.

Since there are several ways to spell #pragma, there are multiple avenues to explore. The Google Sheet from §4. Affected encodings compares the different spellings across encodings in the "Pragma Analysis" sheet

7.1. Use _Pragma("...") where available

In C99 and C++11 _Pragma was standardized as an alternative to #pragma. With this spelling # is not directly required.

However, if the pragma's argument is a string literal, the # or \ characters are still required to escape the argument properly. Unfortunately that is the case for the filetag pragma, therefore this is not a complete solution either.

As demonstrated in the "Pragma Analysis" sheet, this is not a purely theoretical concern. For example, the following encodings can represent both ??=pragma filetag("IBM-1047") and %:pragma filetag("IBM-1047"), but neither one of _Pragma("filetag(\"IBM-1047\")") and #pragma filetag("IBM-1047"):

• EBCDIC-FI-SE
• EBCDIC-FR
• EBCDIC-IT
• EBCDIC-PT
• ISO646-ES
• ISO646-FR
• ISO646-FR1
• ISO646-IT
• ISO646-NO2
• IBM4517
• IBM423

7.2. Partially remove digraphs

Instead of removing all digraphs, we could remove all digraphs except for %: (and possibly %:%:). This would allow users to spell #pragma as %:pragma.

This option seems feasible since %: is relatively harmless - it does not conflict with any other language features in the way <: or %> do and we could still get rid of those.

However, it's not clear whether a tiny amount of actual usage of this feature warrants keeping it around for another couple of decades, especially given that there are other alternatives.

Furthermore, the usage analysis in §5. Usage Analysis shows that being able to spell %:pragma filetag is largely a theoretical concern as compilers still have opt-in support for trigraphs.

7.3. Partially reintroduce trigraphs

Since most if not all code that actually uses #pragma filetag with an encoding that cannot represent # uses the trigraph spelling rather than the digraph spelling, we could also reintroduce just the ??= trigraph. This would allow users to once again spell #pragma filetag as ??=pragma filetag.

As with the other options, this mostly is up to whether the C and C++ committees feel like supporting such encodings is worth the effort.

It also seems rather unlikely that either language is going to reuse ??= for any other purposes anytime soon, meaning that this is a conforming extension either way. If compilers want to keep supporting this, they absolutely can.

7.4. Introduce another alternative spelling for #pragma

Instead of keeping %: around or reintroducing ??=, it might also be viable to just introduce another spelling for #pragma that does not require stringifaction of the arguments.

Particularly interesting for this is that ??= may still be supported as a conforming extension. Therefore, implementations may already conformingly parse ??=pragma as a single token representing a valid #pragma directive, regardless of whether they support trigraphs fully or not.

However, since such pragmas are often wrapped in macro guards, the same may have to be applied to other preprocessor diretives as well.

Since this does not necessarily require any changes to the standard (as it is doable as conforming extension), this is not pursued at this point.

7.5. Deprecate digraphs first

It seems highly unlikely that deprecation is actually meaningful in this case.

Users that still rely on encodings that require digraphs are likely not going to be able to update their code regardless of deprecation warnings or not. This would just delay removal and is not pursued at this point.

8. Wording

Make the following changes to the C++ Working Draft. All wording is relative to [N5054], 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

9. Acknowledgements

Thanks to Corentin Jabot and Hubert Tong for several rather illuminating discussions on the topic.

Thanks to Jan Schultke for the markup language and document generator used for this paper and thanks to all the awesome people who gave feedback on this proposal.

10. References

11. Appendix: Tables of affected encodings

This is an export of the Google sheet in the §4. Affected encodings section.

Please do note that these tables include codecs that are not plausible source encodings. For example BRF is a special-purpose encoding for braille.

11.1. Basic Character Set representability