Hi Thiago,

On 2026-02-10T11:01:40-0800, Thiago Macieira wrote:
> 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.

If misuse is easy, it will happen. We could perfectly design these
tools so that misuse is harder. In C terms, misusing [[reproducible]]
should result in a constraint violation. I think this is viable. The
attribute would have to be part of the function type, to make it
propagate well, and the function could not contain any uses of volatile
lvalues, any static-storage-duration objects, nor any
non-[[reproducible]] function calls.

A language that puts the burden on the programmer is just badly
designed.


Cheers,
Alex

>
> 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.

-- 
<https://www.alejandro-colomar.es>