> On 19 Mar 2025, at 20:52, Marcin Jaczewski <marcinjaczewski86_at_[hidden]> wrote:
>
> śr., 19 mar 2025 o 10:18 Hans Åberg via Std-Proposals
> <std-proposals_at_[hidden]> napisał(a):
>>
>>
>>> On 19 Mar 2025, at 00:16, Andre Kostur <andre_at_[hidden]> wrote:
>>>
>>> Please provide a specific concrete example of this in play to showcase how this attribute would be significantly better than all of the existing alternatives.
>>
>> The example I mentioned first in this thread is:
>> https://gcc.gnu.org/pipermail/gcc-help/2025-January/143945.html
>> GCC has the type std::float128_t on MacOS, but not the functions, as they rely on the C library which comes from Clang which does not have this type implemented.
>>
>> Assume that GCC has the declaration:
>> namespace std{
>> [[unimplemented]] std::float128_t modf(std::float128_t, std::float128_t*);
>> }
>>
>> Then it is possible to implement it in GCC, assuming there is also a new “unimplemented” macro, by:
>> #if QUADMATH_H // Or something
>> #include <quadmath.h>
>> #endif
>>
>> namespace std {
>> #if unimplemented(modf(std::float128_t, std::float128_t*)) // Problem with “,” here
>> std::float128_t modf(std::float128_t x, std::float128_t* y) {
>> __float128 y0;
>> __float128 r = modfq(x, &y0);
>> *y = y0;
>> return r;
>> }
>> #endif
>> }
>>
>> Then it will add the function definition on platforms where it is unimplemented but having the <quadmath.h> library, but add nothing if it is implemented.
>>
>> If Clang later adds support for float128 in its C library, then GCC will also will have it from this library, rather than the added implementation.
>>
>
> Nitpicking:
>> // Problem with “,” here
> why is this a "problem"? Whole point of `()` in macros is to stop
> macro expansion from grouping tokens to separate arguments on `,` .

Right. Was thinking about function macros.

> More serious question: how can preprocessor know what function is
> implemented or not?

Indeed. Something to think about. But one would want to make an implementation that is disabled when the function declaration later on gets “unimplemented” removed.

> You can run prepreocson on a file that is not C/C++ in the first place.
> Only way preprocessor can know anything about C++ is predefined macros like:
> ```
> #if defined(__modf__float128)
> // your code
> #endif
> ```

Yes, but I think C++ does not have that for every function in the library.

> Right now the only sense I see in this proposal is more a
> "placeholder" function for header only libraries.
> This will work only in one TU and with `inline` functions.
>
> You can define:
>
> ```
> void foo() = unimplemented;
> inline void bar() { foo(); }
> ```
>
> and this is valid code, but when you try odr-used `bar` (call or get
> address) then you get an error that refers to an unimplemented
> function.

I thought of giving a warning just saying that the function is unimplemented. If one gets a linker error, one can see what the problem is in the compile.

> This effectively makes it too ` = unimplemented;` abd propagates up to
> other callers function, effectively poisoning everything.
>
> But when you add:
> ```
> void foo() { /**/ }
> ```
>
> Then you are free to call `bar`.

With giving a warning instead of an error, this would be way to remove it. Or by a declaration without “unimplemented” in case the definition is in another translation unit.

> But even if it work this way it will have lot of corner cases like:
>
> ```
> static_assert(unimplemented(bar));
> void foo();
> static_assert(unimplemented(bar) == false);
> ```

The way I think of it, only the function with “unimplemented” is marked as such; it does not propagate to functions calling it (also see below). So in your example, the function is always implemented even though calling an unimplemented function. I haven't thought about static_assert, though.

> Another thing is, this is asking for ODR violations as you grab the
> header with `bar` but forget one with the definition of `foo`.
> This could easily change code `if constexpr (unimplemented(bar))`.
> Probably any way of quarrying `unimplemented` or SFINAE it should be banned.
>
> Another problem is how far it can propagate.

Not at all if it is possible to take the function pointer of an unimplemented function and the linker fills it in if it discovers an implementation.

Anyhow, this is a good point. I cannot tell if it is possible. Something to think about.

> As you can add another
> inline function:
>
> ```
> inline void fiz() { static Func foo = &bar; }
> ```
>
> Technically this is another inline function that could be "poisoned"
> but this `static` value mean "leaking"
> `bar` address and now we need to enforce `unimplemented`? Or we can
> still wait unit function like this is called
> from `main`. Knowing the "creative" way C++ can be abused, this will
> probably quickly become a halting-problem :)
>
> Right now a real life example where I could see this used could be
> some micro controllers.
> You have generic library that is used for many kinds of hardware and
> peripheries but
> in most cases you will use 1% of code from this library and its need
> some specific hooks
> to your proprietary hardware.
>
> ```
> #include "lib_micro.h"
> void lib_micro_logs(const char*) {}
> void lib_micro_exit(int) {}
> void lib_micro_abort() {}
> void lib_micro_set_pin(int, int) {}
> //const char* lib_micro_get_config(const char*) {}
> ```
> Now you can use neary all functions from lib aside from ones that
> indirectly try to call `lib_micro_get_config`.

In the example I gave, one would want have special code for MacOS, but on GNU OS proper, it should be disabled.

Another situation is where one person writes a hack, and then ay leaves the project, so others will have to figure out what it should be and rewrite it. Then it would be best if the original user code part looks as it should be when the C++ language version has been fully implemented, and the hack automatically disabled.