So you essentially want it to work like an "implicit feature testing"? Feature testing macros are generally designed for this, together with constraints.
While I understand that this would be 'easier to write' your own 'work arounds' (or more like back ports), this sort of thing would risk giving very suprising results. And I am honestly not sure you can get it to work like you describe...
// Robin
> On 21 Mar 2025, at 00:15, Thiago Macieira <thiago@macieira.org> wrote:
>
> On Thursday, 20 March 2025 14:39:22 Pacific Daylight Time Hans Åberg wrote:
>>> The most common use will not the in the Standard Library. Please design it
>>> with the most common use-case in mind.
>>
>> The intended design is for use in the standard library.
>
> I don't think so. I don't see the point of this in the Standard Library.
It is for compiler writers who put in options for language versions without full support.
This is what the example I gave is about.
>>> And fixing [[unimplemented]] is still work. If the original party adds the
>>> function, now we have two definitions and the linking may fail (ODR
>>> violations are IFNDR) - it will fail if linking statically.
>>
>> There is no work needed; the workaround implementation will be not called,
>> and its single occurrence can be removed at some point.
>
> It will fail to link. Therefore, it requires work.
The very point is to make is to be able to make a workaround that is automatically disabled when the genuine version arrives
>
>> So forget about the issue, or make your own solution, because this is the
>> only I could find.
>
> To what problem? It isn't clear what you're trying to solve in the first place.
I can only refer you to the earlier posts in this thread.
--
Std-Proposals mailing list
Std-Proposals@lists.isocpp.org
https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals