In C++, this doesn’t work:<\/p>\n\n\n\n
consteval auto square(int x) -> int { return x * x; }\n\nconstexpr auto twice_square(int x) -> int { return square(x); }<\/code><\/pre>\n\n\n\nThe compiler complains, quite rightly:<\/p>\n\n\n\n
error: call to consteval function 'square' is not a constant expression\n\nnote: function parameter 'x' with unknown value cannot be used in a constant expression<\/code><\/pre>\n\n\n\nDespite the fact that twice_square is a constexpr<\/code> function, its parameter x<\/code> is not<\/em> constexpr<\/code>. We can’t use it in a static_assert<\/code>, we can’t pass it to a template, we can’t call an immediate (consteval<\/code>) function with it.<\/p>\n\n\n\nSo far, so well known. This is the current situation in C++, although this area is a potential future expansion of constexpr<\/code> (see P1045<\/a>).<\/p>\n\n\n\nThe Hook<\/h2>\n\n\n\n
And yet… we all know that C++ has some dark corners.<\/p>\n\n\n\n
A disclaimer is in order. I don’t know why the technique I’m about to cover works, and I haven’t found the part of the standard that guarantees it (or not). So the possibilities lie on a spectrum:<\/p>\n\n\n\n
- This is a valid technique, and it’s explicitly called out in the standard
somewhere.<\/li> - This is a valid technique that’s a consequence of a valid reading of perhaps several parts of the standard, but not explicitly called out.<\/li>
- This is known to the standard and left up to implementations, who happen to mostly make the same choice.<\/li>
- This is outside the standard, but a logical consequence of how C++ must be implemented, so implementations are bound to make the same choice.<\/li>
- This is behaviour that is prohibited by the standard.<\/li>
- This is behaviour for which the standard imposes no requirements.<\/li><\/ol>\n\n\n\n
Things in buckets 1, 2 and 3 are well known. Stateful template metaprogramming is an example of something in bucket 4, that the committee would like to move into bucket 5. And bucket 6 is of course undefined behaviour.<\/p>\n\n\n\n
My gut feeling is that we are somewhere in 2-3 territory here. The technique I’m about to highlight is accepted by Clang, GCC and MSVC, and the basics work in every standard since C++11. So 5 seems unlikely. But I could well be wrong — caveat lector<\/em>. And let’s get to it.<\/p>\n\n\n\nThe Tale<\/h2>\n\n\n\nThe most exciting phrase to hear in science, the one that heralds new discoveries, is not \u201cEureka\u201d but \u201cThat\u2019s funny\u2026\u201d<\/p>Isaac Asimov (1920\u20131992)<\/cite><\/blockquote>\n\n\n\nMy suspicions were first aroused while reading a code review recently. The engineer who’d written the code at the time perhaps didn’t appreciate the implication of what they’d written.<\/p>\n\n\n\n
template <auto F>\nconcept C = true;\n\nauto do_something(auto fn) {\n static_assert(C<fn()>);\n}\n\ndo_something([]{});<\/code><\/pre>\n\n\n\nThe actual code is removed to highlight the structure. We’re passing a lambda expression into a function template. And then we’re verifying that the result of calling the lambda satisfies a concept. And by the way, if it’s new to you that concepts can work on NTTPs, that’s also a thing — although it’s not well supported by so-called “terse syntax”.<\/p>\n\n\n\n
But hold on here, fn<\/code> is a function parameter. And function parameters aren’t constexpr<\/code>! So why is the static_assert<\/code> well-formed?<\/p>\n\n\n\nSince C++17, the function call operators of lambda expressions are implicitly constexpr<\/code>. But they aren’t static<\/code> (yet — see P1169<\/a>), so there is an implicit object parameter here that should not be a constant expression – except that the compiler thinks that it is? Again, I’m not sure quite yet what is happening here.<\/p>\n\n\n\nA bit of experimentation shows that this works for lambdas that don’t capture. And for empty structs with function call operators. And for any kind of derived structure, as long as it is empty, including overload sets deriving from several lambda expressions in the familiar way.<\/p>\n\n\n\n
template <typename... Ts> \nstruct overloaded : Ts... { \n using Ts::operator()...;\n};<\/code><\/pre>\n\n\n\nAnd on the MSVC compiler with support for P0847<\/a>, it also works with explicit object parameters.<\/p>\n\n\n\n