This seems rare enough to the point where you wouldn't want a language
feature for it (unless there was an obvious tiny change possible, but there
isn't).

I would assume that
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3294r2.html lets
you build something like "if compiles" yourself though, without using
preprocessor macros. If so, I see no motivation to pursue this as a
distinct core language feature.

On Sat, 6 Dec 2025 at 02:51, Frederick Virchanza Gotham via Std-Proposals <
std-proposals_at_[hidden]> wrote:

> It will take me a few more days to finish the paper on 'chimeric_ptr',
> but while writing it, I've come across another problem.
>
> When we use "if constexpr" with "requires", we can end up with code
> like the following:
>
> if constexpr ( requires { p = &static_cast<Interface&>(*q); } )
> {
> p = &static_cast<Interface&>(*q);
> }
>
> The body of the 'if' statement is duplicated in the 'if' condition. We
> could do away with the duplication as follows:
>
> if compiles
> {
> p = &static_cast<Interface&>(*q);
> }
>
> For now, here's one clunky way to avoid the duplication:
>
> #define IF_COMPILES(...) \
> if constexpr (requires { __VA_ARGS__; }) { \
> __VA_ARGS__; \
> }
>
> I had tried experimenting with a lambda as in the following code, but
> it doesn't compile:
>
> auto try_static = [&]<class Dummy = void>() constexpr
> {
> pI = __builtin_addressof(
> chimeric_detail::static_upcast<Interface&>(*p2) );
> };
>
> if constexpr (requires { try_static(); })
> {
> try_static();
> }
>
> The compiler bails out when the body of the lambda fails to compile. I
> thought having the template parameter 'Dummy' would prevent this, but
> alas it doesn't.
>
> I wonder is it at all conceivable that we could have a core language
> feature, "if compiles"?
> --
> Std-Proposals mailing list
> Std-Proposals_at_[hidden]
> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>