* Jerry Coffin:
[ ... ]
By now you should have understood what "error" means, as the word is
used in the standard and by the OP.
But I'll explain it once more: it means "ill-formed".
Sorry Alf, but here you're just plain wrong.
The standard (at least generally) uses phrasing like "it
is an error if ..." to mean something like "code is ill
formed if ...", that much is true.
The OP, in strong contrast, was clearly using "error" to
mean an error message. Specifically, that the code in
question would NOT be successfully translated.
The standard does not require any such thing under any
circumstances.
The standard requires the implementation to issue a
diagnostic message if any diagnosable rule is violated.
The standard defines the diagnosable rules, and requires
the implementation to define what it considers a
diagnostic.
The marketplace, not the standard, decides anything
beyond that. In particular, most compilers (including the
OP's, apparently) issue a warning for his code. Most
compilers also allow you to elevate warnings to be
treated as error messages (i.e. that code that produces
that message will not be successfully translated). Some
do so only on a blanket basis (i.e. all warnings are
treated as errors) while others allow more selectivity in
doing so -- i.e. you have greater granularity in choosing
which warnings will be treated as errors.
The details of that, however, are clearly specific to the
compiler and off-topic here though, because they have to
do with how you run the compiler, not with the language.
Apart from the phrasing "most compilers" (I really don't think that's
correct) the above sounds eminently reasonable.
It makes it seem as if it's just a matter of degree, outside the scope
of the standard; warning, error, one can be treated as the other,
they're all just diagnostics.
Until you consider the following seemingly conforming C++
implementation, which you can implement in a few minutes time using a
script language. It is a C++ implementation, let's call it OhLaLa
because it is 100% conforming, perfect!, that takes a C++ source file,
or fileset (translation unit that comprises a program), and executes it,
all according to the C++ standard's rules. It's done as follows:
1) If the source code compiles with no errors (output suppressed)
using a compiler B that compiles and only compiles well-formed
source code without errors, delete all result files and issue a
diagnostic "error: out of memory, sorry". This per the "available
resources" clause in §1.4/2 of the standard.
2) Otherwise, if B fails to compile the source code, issue a
diagnostic "warning: extension used", and run a program that spams
all heads of state in Europe (it will always be the same program)
and calls the OS' process exit function; which program, let's call
it S, constitutes the effect of the provided C++ source code. The
language extension is simply that any compilation failure using B
means that the effect of S should be prepended to the effect of the
code minimally adjusted, in some sense, so that it would compile
using B. This is per §1.4/8, which allows extensions that do not
alter the behavior of well-formed programs.
Effectively the OhLaLa C++ implementation is, as I see it, a 100%
conforming C++ implementation when all that's required is what a literal
reading of the standard imposes on a conforming implementation.
However, _I_ wouldn't call OhLaLa a conforming implementation. I would
not even call it a C++ implementation, since the C++ source code does
not influence any effect of submitting the source code to OhLaLa, other
than turning off the single pre-defined effect (and we could, if not for
dramatic impact, turn off that effect so that the C++ source code would
influence absolutely nothing). So as I see it there's something missing
from the literal interpretation picture, and it even begins to seem a
teeny tiny bit unreasonable, don't you think?