Thanks for the link. That is interesting. I can see that we have to take care of what we have created.
Does your company use trigraph?
While we are discussing history, I should give some detail as to how trigraph deprecation came up.
In the last C++ Standard meeting, the Core (Language subcommittee) was processing National Body Comments (search for trigraph here or look for UK 11)
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2009/n2837.pdf
One of the comment from UK 11 was to deprecate trigraphs. This has the effect of a defect request in the C++0x draft standard. It was discussed and despite my lone objection, approved through straw vote to proceed to drafting (and Core issue 789 was opened).
Because trigraph deprecation has the effect of a fix to the C++0x CD1 (Committee Draft 1), a Core language issue was opened and now drafting is being prepared.
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#789
This drafting constitutes a formal proposal. It will be voted in as a language fix during the next meeting's Core sub-committee deliberations when the proposed draft text is reviewed, along with 20-30 other defect fixes to the language that also has proposed text review. The proposed text change is very simple in this case. It will likely move all of Clause 2.4 to Appendix D. All these fixes will be packaged and voted in full plenary at the end of the week ( for which issue 789 will just be one of many) by all national body reps. At that point, if we do not have enough support to reject it, it will be voted into the next C++0x draft. At that point, I suppose someone else can open a Core issue, or a National Body Comment to reverse the decision, but it will be more difficult since the Committee does not like to rehash decisions that have been made.
Appendix D lists all deprecated features. It defines deprecated as:
"Normative for the current edition of the standard, but not guaranteed to be part of the Standard in future revisions."
However, very little is actually ever removed from the Standard. So this, along with many other items may continue to stay in Appendix D for a long time. This means that even if we were to lose, life will go on. However, once deprecated, there is the possibility that trigraph will be reused in another context, and that will definitely break existing code.
It is because this vote will happen in the next meeting (July 12-18 in Germany).. Up to now, there has been enthusiastic support for trigraph deprecation. The reason is because non-expert C++ users can easily confuse trigraphs (which start with ??) with a question mark in strings. As far as I can tell based on a search of our defect report database, our biggest counter argument is that there are several major customers (including ourselves) who are World-wide companies who use a lot of trigraph in their code. There are also serious technical issues such as lack of reasonable replacement using digraphs. But the fact that there are real users who use lots of trigraph, and the unlikelihood that C will remove trigraph, should make it a powerful argument against trigraph deprecation over the inconvenience of getting some confusion for non-expert users (paraphrased from UK 11) because the Standard is supposed to serve the complete user base. The current users of trigraph will be inconvenienced with having to change their code, especially if they want the same file to work in both EBCDIC and non-EBCDIC world, or in the C world, or in strict C++0x Standard compliant mode. For the EBCIDIC world, there is additional powerful argument where it may even be necessary to use trigraph to prevent code-invariant confusion. Basically, I view this as choosing which user-base to serve. As a group, the C++ Standard committee will decide who is more important to serve.: existing users with code using this feature, or future intent to make it easier for non-expert users. Both are important constituents.
As an IBM representative representing our constituent, we must choose to represent existing users and it is important that we make a stand to register our disapproval.
