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
%:.
We would further like to make the following two observations:
-
Usage of ISO 88591 (Latin1), which solves this problem, is becoming
widespread.
-
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 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
of N1443.
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.