Date: Tue, 10 Feb 2026 11:01:40 -0800
On Tuesday, 10 February 2026 03:56:10 Pacific Standard Time Alejandro Colomar
wrote:
> This is part of what makes attributes broken by being ignorable. Or at
> least, depending on what you consider ignorable. [[reproducible]] is
> very dangerous --and will eventually become even more dangerous-- by not
> having mandatory diagnostics on misuse.
>
> Or [[nodiscard]], FWIW, which you can't really trust, because some
> diagnostics might not be generated at all. We need strict diagnostic
> rules, even for ignorable attributes.
Both are cases of misuse. If you tell the compiler the function is
reproducible or won't return, but later turns out you've lied, it's your own
fault. The compiler doesn't *have* to produce a diagnostic, it can trust you,
like it trusts you not to write UB code.
But a conformant implementation that does not make use of the attributes for
code gen does not need to worry about anything. The program is perfectly valid
if the compiler generates code after a noreturn function or repeats calls to
reproducible functions.
wrote:
> This is part of what makes attributes broken by being ignorable. Or at
> least, depending on what you consider ignorable. [[reproducible]] is
> very dangerous --and will eventually become even more dangerous-- by not
> having mandatory diagnostics on misuse.
>
> Or [[nodiscard]], FWIW, which you can't really trust, because some
> diagnostics might not be generated at all. We need strict diagnostic
> rules, even for ignorable attributes.
Both are cases of misuse. If you tell the compiler the function is
reproducible or won't return, but later turns out you've lied, it's your own
fault. The compiler doesn't *have* to produce a diagnostic, it can trust you,
like it trusts you not to write UB code.
But a conformant implementation that does not make use of the attributes for
code gen does not need to worry about anything. The program is perfectly valid
if the compiler generates code after a noreturn function or repeats calls to
reproducible functions.
-- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Principal Engineer - Intel Data Center - Platform & Sys. Eng.
Received on 2026-02-10 19:01:53
