On Sun, 24 Oct 2021 at 21:28, Thiago Macieira via Std-Proposals <std-proposals@lists.isocpp.org> wrote:
Anyway, considering the other posters' solutions to check that the object is
constexpr-constructible, I would feel better if there way a blessed,
standardised way to spell it, instead of everyone rolling out their comma
operator expressions.

It's a bit tricky. The problem is that for full generality, you want to deal with expressions where the inputs and/or outputs may be non-structural, so can't be passed by template even when they are constant expressions.

That means that if you make your library facility something like:

template<auto> struct constant_value_t {};
template<auto A> inline constexpr constant_value_t<A> constant_value;

you still need to use a comma on its operand:

    if constexpr (requires { constant_value<(t.h(n), void(), 0)>; }) {

Here t and n are constant expressions, of course.

And if conversely you encapsulate the comma in a facility:

template<auto F, auto... A> concept constant_invocable =
    requires { constant_value<(F(A...), void(), 0)>; };

the user now has the overhead of writing a non-capturing lambda, passing the arguments in, and it won't work for non-structural argument types:

    if constexpr (constant_invocable<[](T t) { t.h(n); }, t>) {

Quick demo: https://godbolt.org/z/44GKTPv5z

So the library facility here helps somewhat, but it's not much of a win over using bool_constant or simply a lambda with template argument:

    if constexpr (requires { []<auto>().template operator()<(t.h(n), void(), 0)>(); }) {

This is probably an argument for a language level facility (constexpr as predicate?), but well - is there enough pain here to justify it?