Replace "warning" with "diagnostic", or define "warning"

[Eisenwave]

In #7728, @frederick-vs-ja pointed out that:

Hmm, the standard wording is currently saying "warning" for many times:

Ok fair point, I've drafted that PR when I was half-asleep after work and didn't find those for some reason. So it seems like (in N5001) we have:

• 27 occurrences of "warning" in the draft, of which 13 are in normative wording (the rest is comments, #warning, etc.)
• 134 occurrences of "diagnostic" in the draft, of which ... I'm not going to count lmao.

Unlike warning, "diagnostic" is a defined term [defns.diagnostic]. I think we should replace normative uses of "warning" with "diagnostic". To a casual reader, if we say "warning" in some places, that implies that some other messages are "errors", but the standard never makes that distinction. Even an ill-formed program isn't said to produce an "error message". It's all diagnostics.

To further clarify, I think it's fine to keep code comments such as:

0 = 0;  // error
0 == 0; // warning

We use // error comments quite a bit despite never saying what an "error" is, but those uses aren't normative anyway. If "error" is fine in that context, so is "warning". It just isn't fine in normative wording.

[jwakely]

Or add a definition for warning that says it's in the implementation-defined set of diagnostics which might be emitted for well-formed program, with a note or example saying they might be emitted for constructs that might indicate coding mistakes, and for #warning.

Changing normative uses of warning to "diagnostic" removes the distinction between those diagnostics and ones required for ill-formed programs. That would not be helpful. Do you think it's a good idea to say that #warning behaves the same as writing ill-formed code, with no distinction? Please stop suggesting changes that decrease readability and expressiveness of the standard just because they aren't quite precise enough.

The distinction between warnings and errors is real, and useful. If we don't define it properly, the solution is not to remove the distinction entirely.

N.B. all normative uses of "warning" are in Recommended practice: and are useful.

[AlisdairM]

I will speak in support of the original suggestion --- I think it is well motivated, using the Standard terms as they are defined. Nothing in the standard suggests that a diagnostic indicates that a program is ill-formed.

That said, I do prefer Jonathon's suggestion that the correct resolution is to define a new term for warnings; as he says, that change would add information rather than losing it.

[Eisenwave]

@jwakely

Or add a definition for warning that says it's in the implementation-defined set of diagnostics which might be emitted for well-formed program, with a note or example saying they might be emitted for constructs that might indicate coding mistakes, and for #warning.

OK cool. Now what purpose does the definition serve? Emitting a diagnostic message (whether "error" or "warning") doesn't mean that the program is rejected. You're basically standardizing whether the diagnostic is pretty-printed in red or yellow text and has an error: or warning: prefix in a terminal. Subjective connotations such as "this message indicates a coding mistake" apply to error messages just as well as warning messages.

This seems outside the scope of the standard. It also introduces unnecessary problems and questions like

• whether -Werror is compliant,
• whether the set of warnings can be empty,
• whether it is compliant to print errors and warnings in the same color and both prefixed message:, so no distinction exists anyway,
• ...

Changing normative uses of warning to "diagnostic" removes the distinction between those diagnostics and ones required for ill-formed programs. That would not be helpful. Do you think it's a good idea to say that #warning behaves the same as writing ill-formed code, with no distinction? Please stop suggesting changes that decrease readability and expressiveness of the standard just because they aren't quite precise enough.

It's been 30 years and no one bothered to draw a well-defined distinction between "warning" or "diagnostic" yet. #warning and [[deprecated]] are said to produce diagnostic messages. Who cares? This is perfectly fine; I don't see a core issue about it.

In fact, it seems quite deliberate that ill-formed programs result in "diagnostic messages" so that compilers can either error, or warn and accept it with compiler extensions. The vagueness is a feature; doubling down on it increases readability at least.

It's not about "warning" not being precise enough. It's about the distinction being outside the scope of the standard, purely QoI. That makes it a waste of committee time to deliberate whether "warning message", "diagnostic message", or perhaps even "error message" should be used in this or that place.

N.B. all normative uses of "warning" are in Recommended practice: and are useful.

They would be just as useful if they were uses of "diagnostic message".

Also note that 99%+ of "diagnostic" occurrences in the wording (excluding IFNDR) would be replaced with "warning". When programs are ill-formed, a static_assert fails, it's an error. Virtually all other diagnostics (from attributes, Recommended practice specifications, etc.) are warnings, so you'd have a Pyrrhic victory. Replacing virtually all uses of "diagnostic" with "warning" doesn't improve quality.

[frederick-vs-ja]

• whether -Werror is compliant,

Usually not, I think. But we can live with such over-rejection. This is already the status quo and won't be affected by formal definition of warning.

It's conforming to downgrade some errors to warnings, but not the way around.

• whether the set of warnings can be empty,
• whether it is compliant to print errors and warnings in the same color and both prefixed message:, so no distinction exists anyway,
• ...

I believe such settings are compliant. Ditto, won't be affected by a formal definition.

It's not about "warning" not being precise enough. It's about the distinction being outside the scope of the standard, purely QoI.

I guess the intent is using the word "warning" for some diagnostic messages for well-formed constructs, not for all constructs that are not required to be rejected.

[Eisenwave]

Alright, so I've done some digging and gone through the occurrences of "diagnostic" in the standard, excluding ones related to ill-formed programs. Of these, only the following could be replaced with "warning":

• [dcl.attr.deprecated] recommended practice
• [cpp.error] wording for #warning

Yeah ... it's literally just those. Everything else is attached to IFNDR, or deals with erroneous behavior, and EB should intuitively produce an error instead of a warning.

Seeing how small of a change it would be, I'm less opposed to keeping "warning" then. Actually I think I don't care one way or the other at this point.

[frederick-vs-ja]

I think that there're other weird things. Most uses of "diagnostic" are expected to be emitted duration translation (compilation), but there're some diagnostics, namely

• some kinds of diagnostic messages (associated with termination) that are allowed for UB in [defns.undefined],
• recommended diagnostic messages for EB in [intro.abstract]/6, and
• diagnostic messages emitted by failing assert ([assertions.assert]/2),

expected (or even required) to be emitted at run time.

It's unclear to me whether it's intended to use the same term for compile time and run time diagnostics.