[intro.abstract] It is unclear where erroneous behavior diagnostics are issued

[Eisenwave]

Prior discussion at: cplusplus/draft#7730 (comment)

Reference (section label): [intro.abstract] paragraph 6

Issue description

In [assertions.assert], we say that a diagnostic is created "on the standard error stream". One would expect diagnostics emitted as part of erroneous behavior to follow this precedent, but the Recommended practice in [intro.abstract] paragraph 6 does not state where the diagnostic is emitted.

Furthermore, erroneous behavior can occur within a freestanding implementation, but such an implementation may not be capable of producing diagnostics during execution, so the recommendation should not apply to it.

Suggested resolution

Change [intro.abstract] paragraph 6 as follows:

Recommended practice: An A hosted implementation should issue a diagnostic on the standard error stream when such an operation is executed.

[jensmaurer]

Since it's a "recommended practice" and not a normative requirement, it seems harmless to recommend something that cannot be realized on some platforms. In fact, that's usually why we have "recommended practice" utterances: Something we'd really like to have, but sometimes can't be provided. std::source_location::current() comes to mind.

[Eisenwave]

I'm not opposed to keeping "An implementation". It just looks weird when you recommend implementations (including freestanding implementations) to print to stderr. The lack of clarity regarding where the diagnostic is issued is the bigger fish to fry in this issue anyway.

[frederick-vs-ja]

Did you think it makes more sense to output the diagnostic messages to the standard error stream than some other device (e.g. another stream or something shown in GUI)? If not, I don't think we should change the recommendation.

[Eisenwave]

We already recommend that assert should issue diagnostics on the "standard error stream", and it would be surprising if that wasn't the case for erroneous behavior.

It should probably not be stdout because that would be polluting the data the program outputs and pipes into various other places. A GUI may not be available, and it would still be valid to go against the recommendation if it is.

Writing to stderr is simply the only thing that makes sense by process of elimination and has precedent elsewhere in the language.

It's not that important that we output to stderr specifically anyway, but it is important that stdout stays clean.

[frederick-vs-ja]

We already recommend that assert should issue diagnostics on the "standard error stream",

No. This is required, not recommended.

I'd clarify that I'm not recommending alternatives. It seems to me that you thought the standard error stream is the only recommendable output, without which nothing should even be recommended. I doubt whether it is the case.

[Eisenwave]

Yeah, that's true to an extent. I didn't see any viable alternative and thought it's more of a defect that not concrete recommendation was made.

In any case, this change would probably be evolutionary, so whatever.