On Wed, Mar 19, 2025 at 12:48 PM Hans Åberg via Std-Proposals
<std-proposals_at_[hidden]> wrote:
>
>
> > On 19 Mar 2025, at 16:48, Andre Kostur via Std-Proposals <std-proposals_at_[hidden]> wrote:
> >
> > Not that I agree with the proposal, but the scenario I'm hearing:
> > 1) A cpp file includes a header with an [[unimplemented]] function
> > (say the modf example above)
> > 2) That cpp file then includes a header with the same function, but
> > this time without the [[unimplemented]] attribute
> > 3) The cpp file then calls that function.
> >
> > If one was to use =delete instead, #2 would be a compiler error as
> > that would be redeclaring the same function. And if #2 doesn't exist,
> > then the compilation could emit a diagnostic (before it got to the
> > link stage). Though I'm not yet sold that simply not declaring the
> > function at all isn't the better option anyway.
>
> This is just so as to not having to rely solely on linker errors and tables over what is so far implemented in the C++ version. If issuing a warning instead of an error, it will compile if the definition is in some other translation unit, though with a diagnostic message, which then can be suppressed by adding a declaration or a compiler option.

I've been reading through this thread for a while, and it's very
unclear to me what "unimplemented" actually is intended to *mean*. I
understand what you mean for it to *do* in terms of how the compiler
can and cannot behave. But the intended meaning is... slippery.

It seems to me that you want it to mean whatever the person compiling
the code wants it to mean for that compilation. Sometimes, it means
"calling this function is an error." But other times it means "calling
this function is fine; it's just not implemented here." And this
meaning doesn't live in the source code; it lives in the build system
and compiler options.

What this ultimately means is that I cannot read a piece of code
including this attribute and have a clear understanding of exactly how
I can and cannot use that name. If I see `= delete`, that's very
clear: calling this function is an error. If I see `[[deprecated]]`,
that meaning is clear: you can call this now, but it may disappear in
later versions.

But if I see `[[unimplemented]]`... does that mean I can call it or
not? What is the correct way to write code that uses (or doesn't use)
this function? And I'm not a fan of that answer being locked away
inside a build system.

I don't know of any other C++ attributes where the intended meaning of
the code is determined by the build system. Yes, some compiler options
can change exactly how attributes work. But compiler options don't
change the meaning of `[[indeterminate]]`. A compiler could have an
option to fill such bytes in with known variables anyway, but the
meaning of that attribute is that my could *should not* be written
assuming those bytes have any particular value.

If this attribute has different meanings in different contexts, and
I'm supposed to ask the build system what it actually means... then
it's probably not a good feature.