<HTML>
<HEAD>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<TITLE>
    CWG Issue 789</TITLE>
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<STYLE TYPE="text/css">
  INS { text-decoration:none; font-weight:bold; background-color:#A0FFA0 }
  .INS { text-decoration:none; background-color:#D0FFD0 }
  DEL { text-decoration:line-through; background-color:#FFA0A0 }
  .DEL { text-decoration:line-through; background-color: #FFD0D0 }
  @media (prefers-color-scheme: dark) {
    HTML { background-color:#202020; color:#f0f0f0; }
    A { color:#5bc0ff; }
    A:visited { color:#c6a8ff; }
    A:hover, a:focus { color:#afd7ff; }
    INS { background-color:#033a16; color:#aff5b4; }
    .INS { background-color: #033a16; }
    DEL { background-color:#67060c; color:#ffdcd7; }
    .DEL { background-color:#67060c; }
  }
  SPAN.cmnt { font-family:Times; font-style:italic }
</STYLE>
</HEAD>
<BODY>
<P><EM>This is an unofficial snapshot of the ISO/IEC JTC1 SC22 WG21
  Core Issues List revision 118b.
  See http://www.open-std.org/jtc1/sc22/wg21/ for the official
  list.</EM></P>
<P>2025-09-28</P>
<HR>
<A NAME="789"></A><H4>789.
  
Deprecating trigraphs
</H4>
<B>Section: </B>_N4140_.2.4&#160; [<A href="https://wg21.link/lex.trigraph">lex.trigraph</A>]
 &#160;&#160;&#160;

 <B>Status: </B>CD2
 &#160;&#160;&#160;

 <B>Submitter: </B>UK
 &#160;&#160;&#160;

 <B>Date: </B>3 March, 2009<BR><BR>


<A href="http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3086.html#UK11">N2800 comment
  UK&#160;11<BR></A>

<P>[Voted into WP at March, 2010 meeting as document N3077.]</P>

<P>
Trigraphs are a complicated solution to an
old problem, that cause more problems than they solve in
the modern environment. Unexpected trigraphs in string
literals and occasionally in comments can be very confusing
for the non-expert. They should be deprecated.
</P>

<P><B>Notes from the March, 2009 meeting:</B></P>

<P>IBM, at least, uses trigraphs in its header files in conditional
compilation directives to select character-set dependent content in a
character-set independent fashion and would thus be negatively affected
by the removal of trigraphs.  One possibility that was discussed was
to avoid expanding trigraphs inside character string literals, which is
the context that causes most surprise and confusion, but still to
support 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 similar
discussion of universal-character-names in <A HREF="787.html">issue 787</A>.</P>

<P>The consensus of the CWG was that trigraphs should be deprecated.</P>

<P><B>Proposed resolution (September, 2009):</B></P>

<P>See paper PL22.16/09-0168 = WG21 N2978.</P>

<P><B>Notes from the October, 2009 meeting:</B></P>

<P>The CWG is interested in exploring other alternatives that address
the particular problem of trigraphs in raw strings but that do not
require the grammar changes of the approach in N2978.  One possibility
might be to recognize raw strings in some way in translation phase
1.</P>

<P><B>Notes from the March, 2010 meeting:</B></P>

<P>The CWG decided not to deprecate trigraphs, acknowledging that
there are communities in which they are viewed as necessary.  Instead,
it was decided to address what was considered to be the most pressing
issue regarding trigraphs, that is, recognizing trigraph sequences
inside raw string literals.</P>

<BR><BR>
</BODY>
</HTML>
