Thnking about this, I would like to propose that this also needs a syntax for marking that something is an implementation.

Motivation: if something doesn't exist in std:: it is illegal for me to add it. Simialr for third party libraries, while it might be legal C++ to add something to their namespace, it is immoral. However if either marks something [[unimplemtned]] they are then saying that it would be legal for me to add that if I want.

Something like

class ICannotBelieveItIsNotFloat128 {...};

using std::float_128 = myNamespace::ICannotBelieveItIsNotFloat128 [[implements]];

The [[implements]] attribute should raise and error if the thing you are implementing is defined. In the case of float128 we probably don't want to require the full interface (if your code never uses division operators it is okay to not define them). For functions if your function signature doesn't match the library definition it would be an error. (Is this correct - is there any case where a function takes something, perhaps with default options, that an implementation wouldn't wanted to)

To pull this off there needs to be an implementation defined way to bring in my defintion (so that I can build third party libraries with my implementation.) I believe most compilers have this though it is an obsure option.

If I upgrade the library and they now implement the thing, thus removing the [[unimplemented]] attribuite I want a compiler error when my implementation is encountered - since undoubaly this broke ABI.

We should probably require if the thing is in the standard library that the cpp feature deinition now becomes defined as well. Between this and breaking ABI, using those cpp features to decide if you can implement something should not be allowed, but I'm not quite sure how to word this. (perhaps this is just something for books to explain in detail and not the standard itself)

I think the above - giving rules for how someone can use [[unimplemnted]] to implement something if they need it can make the feature helpful. If we don't add those rules though I agree with those who say =delete or just not declaring it at all is good enough.

On Thu, Mar 20, 2025, at 16:14, Thiago Macieira via Std-Proposals wrote:
> On Thursday, 20 March 2025 12:20:09 Pacific Daylight Time Hans Åberg via Std-
> Proposals wrote:
>> The idea is to being able to suppress diagnostics by adding a declaration of
>> the same function without it, in any order of appearance. It would probably
>> be up to the compiler writer to decide what to do.
>
> What happens if someone forward-declares the function? Does this appearance
> cause the compiler to conclude it is implemented? What happens if it is before
> the [[unimplemented]] attribute? What happens if the #include order is not the
> same?
>
> That's why I said this should be another attribute, one which has a higher
> precedence.
>
> What happens if I declare that I am overriding but it wasn't marked
> [[unimplemented]]?
>
> --
> Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
> Principal Engineer - Intel DCAI Platform & System Engineering
>
>
>
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals