P3294 sounds useful, I'll investigate that and consider writing a library.

> Do you feel a need to check an entire if statement body and would this
really save that much typing or redundancy?

Yes. Let's say `template T` is a class representing hardware.

I have a wrapper class that does an initialization sequence requiring
calling a bunch of methods in a given order with different parameters.
However, that init sequence isn't always applicable and I need to fall back
to different stuff.

Since the init sequence involves registers, the names are really long and
I'd rather not retype them. I also have *non*-template dependent code in
the body that's part of the init sequence.

Currently, I have a bunch of macros for detecting member functions and a
lot of variables as a result. Like 10 different variables. Or I can have an
anonymous requires clause that is desynched from the implementation.

> Could you elaborate on how exactly this would work?

My understanding of `if constexpr` is that the conditional instantiation
only kicks in if the code *might* fail depending on the concrete type of T
(+ the invalid type forming thing). You can't gate something behind `if
constexpr` if it's always a compilation error.

An `if compiles (T)` would go further and check that the body is
instantiable based on the deduction of `T`, ignoring other types. So `if
compiles (T) {T::foo(); S::bar();}` would be the equivalent of

`if constexpr ( requires { T::foo();}) {
T::foo();
S::bar();
}`

However it sounds like I'd rather be using P3294.

On Sat, Dec 6, 2025, 1:03 p.m. Jeremy Rifkin <jeremy_at_[hidden]> wrote:

> > I often have template functions where I want to test for the presence
> of an operation and fall back to something else.
>
> Testing the presence of an operation is something that requires
> expressions are very good at already. Do you feel a need to check an entire
> if statement body and would this really save that much typing or redundancy?
>
> > 1, 2, and 3 could be addressed with an option to explicitly name the
> type being reflected on
>
> Could you elaborate on how exactly this would work?
>
> Jeremy
>
>
> On Fri, Dec 5, 2025 at 21:56 JJ Marr <jjmarr_at_[hidden]> wrote:
>
>> This might actually be useful. I often have template functions where I
>> want to test for the presence of an operation and fall back to something
>> else. For example, if the equality operator is defined for two types I'd
>> use that, otherwise I'd compare their members.
>>
>> Likewise I often test for multiple member functions as a form of
>> reflection. This makes this practice more concise.
>>
>> 1, 2, and 3 could be addressed with an option to explicitly name the type
>> being reflected on (or use auto).
>>
>> This would be more useful to me than chimeric_ptr.
>>
>>
>> On Fri, Dec 5, 2025, 9:53 p.m. Jeremy Rifkin via Std-Proposals <
>> std-proposals_at_[hidden]> wrote:
>>
>>> Hi,
>>>
>>> How often is code written like this? Is this a big enough problem to
>>> warrant a new language feature?
>>>
>>> A couple things stand out to me:
>>>
>>> 1. Generally you want to test specific properties about a type or types
>>> in a requires expression, not an entire if statement body with arbitrary
>>> possible mistakes, potentially unrelated to the types you actually want to
>>> inquire about. This makes the construct inherently bug-prone and could lead
>>> to some potentially very difficult to diagnose situations.
>>> 2. Code written as “if compiles { body }” doesn’t strike me as
>>> particularly expressive or nice to read. If statements read as “if
>>> condition, do xyz,” reading “if compiles” leaves me wondering if what
>>> compiles? Then what?
>>> 3. Would this check all possible ill-formed bodies that don’t compile or
>>> only the ill-formedness that requires expressions check for (i.e. those
>>> pertaining to forming invalid types and or violating semantic constraints
>>> as a reduction of template argument substitution)? If the first, that
>>> strikes me as unimplementable. If the later, the name is misleading.
>>> 4. There are constraints on what can go in requires expressions, I don’t
>>> think existing machinery exists for arbitrary if statement bodies.
>>>
>>> Cheers,
>>> Jeremy
>>>
>>> On Fri, Dec 5, 2025 at 19: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
>>>>
>>> --
>>> Std-Proposals mailing list
>>> Std-Proposals_at_[hidden]
>>> https://lists.isocpp.org/mailman/listinfo.cgi/std-proposals
>>>
>>