Standards love to add things. They remove very little, but they do like to deprecate. This post will describe a collection of things that is heading that way, or not heading that way in C++ 0x.

In my posting on Intention to deprecate trigraphs in the next C++ Standard, we successfully demonstrated that much of the non-English speaking world will still need to rely on trigraphs as a way to get to UCN through "\" which may be inaccessible in some codepages. So we would object to deprecating it without an alternative.

In the last meeting in Santa Cruz, an alternative was proposed in Core issue 789:Replacing Trigraphs. In short, it does not so much deprecate trigraphs (which we like) as move trigraphs out of translation phase 1 so trigraphs are not recognized ahead of raw strings, but is still recognized ahead of other strings (as it is now). It seems that trigraph interaction with raw strings was always the real issue behind the original National Body comment. This interaction had become more prevalent because Raw strings are accepted as part of C++0x. This proposal will level the playing field to what it was again.

We reviewed the paper as a way of fixing the interaction of trigraphs and raw strings. We think the paper is ready to go, but we're holding it back because we're considering other approaches, including moving UCNs out of translation phase 1 or moving raw string recognition into phase 1.

We're still looking at deprecating exception specifications. Our current feeling is that we will deprecate them except for the ways of saying a function doesn't throw at all (e.g., the new noexcept feature, still being reviewed). This feature has been shown to be relatively useless since its inception.

We did a straw poll on deprecating or removing exported templates. I voted to support removal of export to reduce dialecting C++. However a straw poll in full committee seems to prefer deprecation. This feature has been implemented exactly by one company, and even their lead is not opposing its removal. We appreciate their selfless sense of the C++ community and appreciate their sacrifice in learning about why this feature was problematic. Sometimes, it does take doing to see the whole picture.

Finally, we deprecated the semantics of the register keyword. This keyword has been ignored by most compiler that I am aware of, so it is the right time to deprecate it.

As with all deprecation, have no fear. All compilers will generally continue to accept (and or ignore) these cases, so that your code will continue to compile.

Do you use trigraphs?
If so, you may be interested that the C++ Standard Committee will vote to deprecate trigraphs (to Appendix D) in the next meeting in July 12-18 in Frankfurt as I discussed in my last trip report:
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard/2009/05/27/the-view-or-trip-report-from-the-mar-2009-c-standard-meeting

Trigraph sequences are

??= # pound sign
??( [ left bracket
??) ] right bracket
??< { left brace
??> } right brace
??/ \ backslash
??’ ^ caret
??! | vertical bar
??- ~ tilde

One of the reason they were invented was because a character like '#' have code points that differ across EBCDIC code pages.
It is safe to use '?' and '=' because these share the same code point across all EBCDIC code pages.
Another reason is that on some international keybaords, these characters do not have representation and they must be typed in using this sequence of text. They get replaced in quotes because they are handled in phase 1 of translation and can be replaced even if found inside another token, such as a quoted string, or character constant.

There are some possible alternatives. Digraph supply a subset of trigraphs:

But it does not represent these trigraphs and cannot be a complete replacement:
??! |
??' ^
??/ \
??- ~

Digraphs also are handled during tokenization and must always be a full token by itself. This means it will not be replaced inside quotes.

Now you can use something like an alternative spelling for operators to cover 3 of those 4 cases:
bitor
or
or_eq
xor
xor_eq
compl

But one of those four, '\' truly has no replacement possibility.

Even in the ASCII world, the loss of trigraphs can be problematic if a keyboard does not have backslash. Does this happen? I would like to know.
Loss of backslash also can lead to other characters that are variant, including the half-width backslash in Japanese, and the yen sign in Shift-JIS.

So why is there enthusiasm for this deprecation?

It is precisely because of the ability to replace trigraphs in quotes. They can look like question marks, and in some cases they are especially when inside a quoted string. There is cause for confusion. Specifically, one National Body comment urge the removal of trigraphs because:
'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. "

Are there others, I would like to know. Some folks have mentioned how this can be a problem is modern Perl searches.

I would be interested if you agree with these statements and what opinion you may have on the deprecation of trigraphs.