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 Fri, Mar 21, 2025, 09:14 Hans Åberg via Std-Proposals <
std-proposals_at_[hidden]> wrote:

>
>
> > On 21 Mar 2025, at 00:15, Thiago Macieira <thiago_at_[hidden]> 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_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>