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
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.
We would further like to make the following two observations:
- The solution in N1341 is both incomplete and overcomplete.
Incomplete because no solution is offered inside strings and
Overcomplete because, to remain consistent
with macro definitions for characters in the variant subset, it
also contains macro definitions for the invariant subset;
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
Standardization of macro definitions is, strictly speaking, not
Users can create their own sets of definitions, without
The use of the macro names
is to be used as replacement for the assignment operator
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
The proposal in clauses 2, 3 and 4.4 is not good enough to be acceptable,
even as a compromise.
Especially because it solves a disappearing problem.
We see no reason to burden the international community with this part
Usage of ISO 88591 (Latin1), which solves this problem, is becoming
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.