Keith Thompson said:
Tim Rentsch said:
I would want a diagnostic to be mandatory; the simplest way to make
that happen is to make it a syntax error, by removing 'non-directive'
from the grammar. [snip]
The /simplest/ way would be to add a statement saying that a
diagnostic is mandatory. Changing the syntax would mean
making a number of other changes in the subsequent text
of 6.10 and 6.10.x
The simplest way would be to make it a constraint violation;
I'm not sure I agree; more below.
the requirement for a diagnostic would fall out of that.
Explicitly stating that a constraint is required would add a fourth
special case to the existing things that require diagnostics: syntax
errors, constraint violations, and #error.
The word 'constraint', especially as defined in 3.8p1, doesn't
describe the situation with non-directive very well. Making
executing a non-directive be a constraint violation would require
issuing a diagnostic, but this rule isn't so much a "restriction" as
a "prohibition". It seems likely that this same reasoning (or
similar reasoning) is why '#error' is defined as requiring a
diagnostic, rather than being identified as under a Constraints
section.
I understand the desire not to add more cases (be they special or
otherwise) to the set of things that require a diagnostic. At the
same time, it's not a good idea to lump something in with an existing
category, just for the sake of convenience, if it doesn't really fit
in that category. In my opinion the situation with 'non-directive'
is different enough from other conditions identified as Constraints
to think that this term may not be appropriate here. To say this
another way, I think the situation with 'non-directive' is more like
'#error' than it is like a constraint violation; if the Standard is
going to be consistent in how it uses terminology, then either both
'#error' and 'non-directive' should be constraint violations or
neither should be [assuming that we want 'non-directive' to require a
diagnostic, which I'm taking as a given for the sake of discussion].
I think I understand the reasoning that went into the decision on how
to handle '#error'; since the same reasoning seems to apply to
'non-directive', unless there's an argument I haven't thought of yet,
then just giving an explicit statement that a diagnostic must be
issued seems like the better course.
Returning to the larger issue, maybe the best way to clear up what's
going on with 'non-directive' would be to write a 'Recommended
practice' paragraph or two saying that encountering a 'non-directive'
should produce a diagnostic message, perhaps depending on a compiler
option that allows some implementation-specific preprocessing
directives. There is some precedent for such a provision, namely,
6.4.4.2p6 (and for convenience here it is):
The implementation should produce a diagnostic message if a
hexadecimal constant cannot be represented exactly in its
evaluation format; the implementation should then proceed
with the translation of the program.
Of course the specific wording for 'non-directive' would be
very different, but the general approach might be a good
idea here considering the current state of affairs.