This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21 Core Issues List revision 119a. See http://www.open-std.org/jtc1/sc22/wg21/ for the official list.
2025-12-20
[Voted into WP at March, 2010 meeting as document N3077.]
Trigraphs are a complicated solution to anold problem, that cause more problems than they solve inthe modern environment. Unexpected trigraphs in stringliterals and occasionally in comments can be very confusingfor the non-expert. They should be deprecated.
Notes from the March, 2009 meeting:
IBM, at least, uses trigraphs in its header files in conditionalcompilation directives to select character-set dependent content in acharacter-set independent fashion and would thus be negatively affectedby the removal of trigraphs. One possibility that was discussed wasto avoid expanding trigraphs inside character string literals, which isthe context that causes most surprise and confusion, but still tosupport them in the rest of the program text. Specifying that approach,however, would be challenging because trigraphs are replaced in phase 1,before character strings are recognized in phase 3. See also the similardiscussion of universal-character-names inissue 787.
The consensus of the CWG was that trigraphs should be deprecated.
Proposed resolution (September, 2009):
See paper PL22.16/09-0168 = WG21 N2978.
Notes from the October, 2009 meeting:
The CWG is interested in exploring other alternatives that addressthe particular problem of trigraphs in raw strings but that do notrequire the grammar changes of the approach in N2978. One possibilitymight be to recognize raw strings in some way in translation phase1.
Notes from the March, 2010 meeting:
The CWG decided not to deprecate trigraphs, acknowledging thatthere are communities in which they are viewed as necessary. Instead,it was decided to address what was considered to be the most pressingissue regarding trigraphs, that is, recognizing trigraph sequencesinside raw string literals.