The case against digraphs and iso646.h

The British Standards Institute (BSI) and the Nederlands Normalisatie Instituut (NNI) both voted against Normative Addendum 1 (which was then still called N1443), but would have changed their votes to `Yes' had the Danish proposal been removed from it.  The NNI kindly allowed us to reproduce the text of its formal vote (which the BSI agreed with) on the Addendum.

The NNI regrets that it has to vote against SC22/N1443.  The NNI does not wish to support the solution offered for the usage of C with national variants of the ISO 646 character set.  This solution is contained in clauses 2, 3 and 4.4 of N1443. 

There is pressure from countries using national variants of ISO 646 to have a standard way of expressing C in the invariant subset of ISO 646 that is more aesthetically pleasing than the trigraph solution that is embedded in the current C standard.  We understand their whish.  But we have come to the conclusion that we do not see an acceptable way of realizing this whish.  We see three criteria for proposed solutions: completeness, aesthetics and technical cleanness.

• The solution in N1341 is both incomplete and overcomplete.  Incomplete because no solution is offered inside strings and literal characters.  Overcomplete because, to remain consistent with macro definitions for characters in the variant subset, it also contains macro definitions for the invariant subset; e.g. and_eq for &=, because or_eq needs to be defined as |=.

• The result is barely aesthetically acceptable.

• The proposal is technically feasible, but unsatisfactory.  The solution uses two technically different approaches to solve the same problem; alternate spelling of tokens and macro definitions. 
  Standardization of macro definitions is, strictly speaking, not necessary.  Users can create their own sets of definitions, without threatening portability.
  The use of the macro names and_eq and not_eq is confusing.  and_eq is to be used as replacement for the assignment operator &=, while not_eq is to be used as replacement for the comparison operator !=.
  The proposal also seems to be in conflict with the emerging C++ standard with respect to the digraphs <: and %:.

1. Usage of ISO 8859­1 (Latin­1), which solves this problem, is becoming widespread.

2. We expect that the proposed solution will be little used.  Programs written in the ISO 646 invariant representation of C look so different from the current representation that they will be hard to maintain for people used to the current representation i.e the rest of the world.  We expect that for this reason a large part of the community in countries that stated interest in this proposal will keep on using the current representation of C. 
   Furthermore, only a few of the countries with national variants of ISO 646 have expressed interest in this proposal.

The rest of N1443 is a worthwhile document that we welcome. We will support N1443 if the objections mentioned above are taken away by removing the clauses 2, 3 and 4.4.