A “backdoor pilot” conference trip report

Similarly to how TV shows sometimes insert “backdoor pilots” into their episodes, I’m doing the same here.

—–BEGIN TANGENT—–

I don’t have enough important things to say about CppCon and NDC TechTown to warrant a full article, but I had a great time at both, and I have a couple particular things I wanted to mention here, among my few-times-per-year-typing-into-the-void that is my blog posts.

I spoke at both CppCon 2026 and NDC TechTown 2026, about GDB pretty-printers. I got the same talk accepted at both conferences, so the talks had the same title and abstract, but I wanted to make the contents different. In the end, I made one very long slide deck that I split into 2 parts. Both talks had the same first ~25 minutes, and then the rest of each talk was unique. My main point remains the same, that we always need to be testing the code that we write, and that includes pretty-printers. I’ll write another article about my GDB pretty-printer unit testing library, that I spoke about in my talks. It was an honour and a pleasure to be able to speak at both of these conferences.

For the first time ever at CppCon we decided to fill the exhibitor tables with community groups on the Thursday and Friday, when many of the exhibitors tend to leave. There’s still more to be done in the coming years, but it made the halls feel much more alive. One of the tables was for WG21, where we had a physical presence so anyone could walk by and ask questions face-to-face. It was lovely to speak with people! Hopefully next year we’ll have even more community exhibitors. If you’re reading this post and you want to see a table representing a particular community organization on the Thursday and Friday of CppCon next year, get in touch with me.

The biggest highlight of CppCon for me was a particular phrase that Ben Deane accidentally coined on the spot. I can’t remember the exact details of the conversation, but we were discussing the idea of “standing on the shoulders of giants”, and the strange process of actually becoming those aforementioned “giants”. Then he said, (sharing this quote with permission),

Take your place in the tower of giants.

I immediately froze, looked him straight in the eye and said, “Are you quoting something?”, to which he said “No, I just said that”, to which *I* said, “That’s incredible, I need to write this down”. And I did, which is how I know what he said verbatim. So this is me sharing that amazing coinage with the world. I have thought about this nearly every day since it happened a few weeks ago. The main reason I’m even writing this section of this article is because of this amazing quote.

NDC TechTown was a lot of fun. Much shorter than CppCon, but much less work for me as just a regular speaker-and-attendee. The sense of community at NDC TechTown is incredible. I hope to get the chance to attend again. Anders Knatten’s live edition of CppQuiz was quite fun, but way more difficult than I had anticipated! Who knew C++ was hard.

—–END TANGENT—–

Where we left off

In the last article, I first showed this code, which failed in both MSVC and Clang.

struct S{};

template <class T>
void foo(T) {
    (void)[]<class U>(U) consteval -> bool {
        return requires { 0 * T{}; };
    }(0);
}

void bar() {
    foo(S{});
}

In Clang, I reduced it down to this minimal repro, which still showed the same issue. I opened llvm/llvm-project#205218, and it turns out to be a duplicate of llvm/llvm-project#35052.

template <class T = void>
void foo() {
    [](auto) consteval -> void {
    }(0);
}
int main() {
    foo();
}

This was worrying, because it means that generic lambdas cannot be evaluated at compile-time. I think sometimes they can be, and I was fortunate enough to only encounter those cases previously, but now I’m running into this bug.

Because I’m writing a unit testing library focused around compile-time testing, the inability to evaluate generic lambdas at compile-time could kill the project, at least with the API I want.

Why do we need generic lambdas?

I have this macro, K3_K3TCHUP_EXEC_PACKET_(PACKET). This is a macro that’s internal to the library, and it must handle “packet” execution. In k3tchup, a “packet” is the name that I give to an invocable that encapsulates further test logic. Originally, I needed each packet to just be nullary invocable, so PACKET() would need to be a valid expression. However, now I have a 2nd kind of packet, which is invocable with an lvalue opaque “state” object. I need both of these packets to be handled, and I want them to be handled from the same macro.

I can’t do dispatching in the preprocessor, as invocability is a semantic requirement, much after the preprocessor. Simplifying some identifiers, this is what I want the macro to look like. Note that K3_K3TCHUP_EXEC_PACKET_STATEFUL_ is a macro to contain some more non-trivial logic.

#define K3_K3TCHUP_EXEC_PACKET_(PACKET)                   \
    {                                                     \
        using T = decltype(PACKET);                       \
        if constexpr (std::invocable<T>) {                \
            (PACKET)();                                   \
        } else if constexpr (std::invocable<T, state&>) { \
            K3_K3TCHUP_EXEC_PACKET_STATEFUL_(PACKET);     \
        } else {                                          \
            static_assert(false);                         \
        }
    }

This looks great. What’s the problem?

Don’t read ahead if you want to figure it out for yourself.

…

The problem is that this isn’t a template context. Or at least, it might not be a template context.

Imagine this calling scenario, which is about as simple as it gets.

void foo() {
    K3_K3TCHUP_EXEC_PACKET_([](state&) {});
}

If we do just 1 round of expanding the macro, this function becomes:

void foo() {
    {
        using T = decltype([](state&) {});
        if constexpr (std::invocable<T>) {
            ([](state&) {})();
        } else if constexpr (std::invocable<T, state&>) {
            K3_K3TCHUP_EXEC_PACKET_STATEFUL_([](state&) {});
        } else {
            static_assert(false);
        }
    };
}

But because this isn’t a template, the if constexpr statements don’t work as we might expect. There is nothing that’s dependent on a template parameter, so the compiler is free to evaluate the constants when encountering them. Ultimately the compiler sees this:

void foo() {
    {
        if constexpr (false) {
            ([](state&) {})();
        } else if constexpr (true) {
            K3_K3TCHUP_EXEC_PACKET_STATEFUL_([](state&) {});
        } else {
            static_assert(false);
        }
    };
}

Outside of a template context, if constexpr doesn’t work the same way. Using if constexpr (false) doesn’t stop the enclosed statements from being semantically checked. So in this case, the compiler runs semantic analysis on ([](state&) {})();, and we get a hard error. Not to mention the static_assert(false); which would also net an error.

I need some way to do this dispatching, and if constexpr is the tool in my tool belt. So let’s just wrap this whole thing inside an immediately invoked lambda, and make sure the lambda is generic so we can depend on the template parameter.

#define K3_K3TCHUP_EXEC_PACKET_(PACKET)                   \
    [&]<class T>(std::type_identity<T>) {                 \
        if constexpr (std::invocable<T>) {                \
            (PACKET)();                                   \
        } else if constexpr (std::invocable<T, state&>) { \
            K3_K3TCHUP_EXEC_PACKET_STATEFUL_(PACKET);     \
        } else {                                          \
            static_assert(false);                         \
        }                                                 \
    }(std::type_identity<decltype(PACKET)>{})

Here, the compiler won’t eagerly evaluate the statements that were previously eagerly evaluated. Even though this lambda is called exactly one time, and we can see with our eyes exactly what will happen, the compiler does not do the same thing as before.

Therefore, after all this, it seems that we need to use generic lambdas here.

Alright, but why do we need generic lambdas executed at compile-time?

Previously, in my library, the nullary invocable packet was itself only ever executed at run-time. Even though within the packet, you could have many statements executing at compile-time. Here is a code example.

EXPECT_THAT([]{
    EXPECT_COMPILE_TIME(1 == 2);
});

In this case, the expression 1 == 2 is only invoked at compile-time, but the lambda itself is only invoked at run-time. Because the lambda is only invoked at run-time, any template machinery that’s encapsulated in the EXPECT_THAT macro also probably involves running things at run-time. So even if I wrapped the logic in an immediately-invoked generic lambda, it would only execute at run-time.

With the new type of packet, for “stateful” checks, I’ll need to execute the packet twice: once at compile-time and once at run-time. With that change, we can have some nicer syntax that looks like this.

EXPECT_THAT([](auto& state) {
    std::optional<int> o = foo();
    ASSERT(state, o.has_value()) << "optional did not have a value";
    EXPECT(state, *o == 5) << "optional's value was not 5";
});

Because the packet itself (i.e. the lambda) must be executed once at compile-time and once at run-time, then whatever template machinery is encapsulating it would also need to have statements executing both at compile-time and run-time. Without these “stateful” checks, the best we could do is this:

EXPECT_THAT([]() {
    ASSERT(foo().has_value()) << "optional did not have a value";
    EXPECT(*foo() == 5) << "optional's value was not 5";
});

In this example above, the entire lambda itself is only executed at run-time. However, the ASSERT and EXPECT statements’ expressions get executed once at compile-time and once at run-time. That means we have to call foo() for every check that uses its result, instead of just once at the beginning of the packet body.

In my opinion, the “stateful” checks potentially allow for a cleaner syntax. However, in the pursuit of a cleaner syntax, I discovered these Clang edge cases.

Getting started without generic lambdas

Here’s the general form of what we need.

#define K3_K3TCHUP_EXEC_PACKET_(PACKET)                   \
    {                                                     \
        using T = decltype(PACKET);                       \
        if constexpr (std::invocable<T>) {                \
            /* 1. PACKET() in a way that doesn't fail */  \
        } else if constexpr (std::invocable<T, state&>) { \
            K3_K3TCHUP_EXEC_PACKET_STATEFUL_(PACKET);     \
            /* 2. Also make sure this doesn't fail */     \
        } else {                                          \
            /* 3. Something like static_assert(false) */  \
        }
    }

Starting with number 3 is the easiest. Just throw;. It’s really all we can do. Because this macro can be called from a non-dependent context, we can’t rely on any static_assert at all. There’s nothing stopping it from failing every single time. So we need some run-time mechanism.

This also begs the question as to whether if constexpr is actually doing anything here. Truthfully, I’m not 100% sure. It feels wrong not to use if constexpr, since the conditions are compile-time-only, but if wouldn’t actually change the meaning here. All the statements are semantically checked in all branches.

To solve number 1, I decided to write a function template called invoke_packet_nullary. This has to be a template, because we need to somehow conditionally execute the packet, only when that’s a valid operation to do. It could have also been 2 overloads, but I prefer if constexpr, as below.

template <class F>
constexpr void invoke_packet_nullary(F&& f) {
    if constexpr (std::invocable<F&&>) {
        static_cast<F&&>(f)();
    }
}

Note, we are allowed to use templates, we just can’t use generic lambdas. That’s why calling out to this function is fine, but putting it in-line is not. This idea will come in handy again later.

With this function, it’s now completely valid to call invoke_packet_nullary([](state&) {}). This call would just do nothing. This call will never actually happen, because it’s gated behind if constexpr (false), but the compiler needs to do the semantic checking anyway.

Handling the K3_K3TCHUP_EXEC_PACKET_STATEFUL_ macro

Alright, hold on to your seats. This is the “number 2” from the above section. The K3_K3TCHUP_EXEC_PACKET_STATEFUL_ macro, after simplifying the identifiers, does this. This is without any modifications for the Clang issues.

#define K3_K3TCHUP_EXEC_PACKET_STATEFUL_(PACKET)        \
    const state ct_state =                              \
        state_accessor::deserialize([&]() consteval {   \
            constexpr auto sizes = [&]() consteval {    \
                auto s = state_accessor::make();        \
                (PACKET)(s);                            \
                return state_accessor::sizes(s);        \
            }();                                        \
            auto s = state_accessor::make();            \
            (PACKET)(s);                                \
            return state_accessor::serialize<sizes>(s); \
        }());                                           \
    state rt_state = state_accessor::make();            \
    (PACKET)(rt_state);                                 \
    state_accessor::report(ct_state, rt_state)

The point of my state type is to be as inert as possible. It should have zero allowable operations from the user’s perspective, including constructors, so I need this internal type state_accessor to take the place of what would be member functions.

In this macro, I do a sort of “constexpr 2-step”. I call (PACKET)(s) once at compile-time to simply grab the “sizes”, i.e. the amount of storage in bytes that’s needed to serialize all the error messages. Then I call (PACKET)(s) again, and this time I serialize the results out into a statically sized std::array based on the previously obtained sizes. This is all at compile-time. Then at run-time, this statically sized std::array is deserialized back into its original form. Note that this means the compile-time side of the test is running twice.

At run-time, I also need to call (PACKET)(s), and this becomes the run-time result. No serialize-deserialize needed, as it’s all run-time. In this library, all errors are meant to be reported at run-time, even for the compile-time failures.

This macro does not work in its current form. The expression (PACKET)(s) will fail when the packet looks like [](){}, even though it’s gated behind if constexpr (false).

Let’s tackle this bit-by-bit.

First, the part where I grab the size in bytes. At the moment in the library, it is expressed as this struct.

struct flat_state_sizes {
    std::size_t count;
    std::size_t total_chars;
};

I can grab the sizes at compile-time easily, with a call to a function template. Originally I did something FAR more complicated than below, but that’ll be in a later section.

template <class F>
consteval flat_state_sizes get_packet_sizes(F&& f) {
    if constexpr (std::invocable<F&&, state&>) {
        auto s = state_accessor::make();
        static_cast<F&&>(f)(s);
        return state_accessor::sizes(s);
    } else {
        return {};
    }
}

If we can execute this as a stateful packet, then do that. Otherwise return empty.

Then I’ll create another helper function packet_serialize to do a similar thing, but for the serialization step. This function takes the result of the previous function as a template parameter.

template <flat_state_sizes sizes, class F>
consteval flat_state<sizes> packet_serialize(F&& f) {
    if constexpr (std::invocable<F&&, state&>) {
        auto s = state_accessor::make();
        std::forward<F>(f)(s);
        return state_accessor::serialize<sizes>(s);
    } else {
        return state_accessor::serialize<sizes>(state_accessor::make());
    }
}

Along with one last helper function invoke_packet_stateful(F, state&), similar to invoke_packet_nullary, this is what the new K3_K3TCHUP_EXEC_PACKET_STATEFUL_ macro looks like, with simplified identifiers.

#define K3_K3TCHUP_EXEC_PACKET_STATEFUL_(PACKET)            \
    {                                                       \
        constexpr auto sizes = get_packet_sizes(PACKET);    \
        const state ct_state = state_accessor::deserialize( \
            packet_serialize<sizes>(PACKET)                 \
        );                                                  \
        state rt_state = state_accessor::make();            \
        invoke_packet_stateful(PACKET, rt_state);           \
        state_accessor::report(ct_state, rt_state);         \
    }

Remember, none of this will actually get run in the nullary case. We just had to make sure that it’s semantically valid. And now it is! So we got exactly the same behaviour, without wrapping in any generic lambdas!

What I actually did, based on incorrect assumptions

I lied in that last section. I didn’t write it like this. I should have, but I didn’t. I had some wrong assumptions, and I’ll go over them here.

Every one of the following points is wrong, and I’ll explain what I did as a result of each one.

1. The functions get_packet_sizes and packet_serialize must be callable at run-time for the case of nullary invocable packets
2. get_packet_sizes needs to return a different type for the case of nullary invocable packets
3. Detecting which overload of get_packet_sizes would be called is not possible in standard C++

Remember, all of these assumptions are wrong. But they made me write some wild code that somehow does the right thing. This wild code I wrote is exactly why I wanted to write this article in the first place

Because of item 1, I used overload sets instead of if constexpr, since we can’t parametrize the constexpr/consteval-ness of a function. For example, I actually wrote this.

template <class F>
requires (not std::invocable<F&&, state&>)
constexpr int get_packet_sizes(F&&) {
    return 0;
}

template <class F>
requires std::invocable<F&&, state&>
consteval flat_state_sizes get_packet_sizes(F&& f) {
    auto s = state_accessor::make();
    static_cast<F&&>(f)(s);
    return state_accessor::sizes(s);
}

Notice that one of these functions is marked constexpr and the other is consteval. For the actual case that gets executed, I want it to only get executed at compile-time, thus consteval. There’s no reason that overload should ever be called at run-time. But for some reason, I was wholeheartedly convinced that the other one had to be called at run-time sometimes. I must have mistaken some error messages.

This brings me to item 2, that I thought the return type needed to be different. I used int as a dummy type, since I thought I would need to overload on this type later on, in the function packet_serialize, even though I’m already overloading on the kind of packet I’m receiving. This is what I wrote.

template <auto Value>
using constant = std::integral_constant<
    std::remove_cvref_t<decltype(Value)>, Value>;

template <int dummy, class F>
requires (not std::invocable<F&&, state&>)
constexpr flat_state<flat_state_sizes{}> packet_serialize(constant<dummy>, F&&) {
    return state_accessor::serialize<flat_state_sizes{}>(state_accessor::make());
}

template <flat_state_sizes sizes, class F>
requires std::invocable<F&&, state&>
consteval flat_state<sizes> packet_serialize(constant<sizes>, F&& f) {
    auto s = state_accessor::make();
    static_cast<F&&>(f)(s);
    return state_accessor::serialize<sizes>(s);
}

While, yes, I am overloading on the type of constant given, that’s unnecessary. It could easily be just an empty flat_state_sizes. Overloading on the type of the constant is only needed if I don’t also have the std::invocable constraints. Again though, that’s not why I wrote this as 2 separate overloads. As before, I wrote 2 overloads instead of 1 function template because I thought one needed to be constexpr and the other consteval.

As for item 3, this is where it got really strange. Because get_packet_sizes returned 2 different types, I needed to conjure some expression that would do the right thing in both cases. Here is what could have worked.

constexpr auto sizes = get_packet_sizes(PACKET);

And here is what I actually wrote.

struct converter {
    template <class T>
    constexpr operator T() const {
        return T{};
    }
};

// Later, inside K3_K3TCHUP_EXEC_PACKET_STATEFUL_:
constexpr auto sizes = __builtin_constant_p(get_packet_sizes(PACKET))
    ? get_packet_sizes(PACKET) : converter{};

What I will say, is that after writing this code, everything worked perfectly.

Because get_packet_sizes(PACKET) might return different types, I needed the other side of the ternary expression to be something convertible to both. And this ternary expression would be controlled on whether get_packet_sizes(PACKET) is callable at compile-time at all.

I was so proud that I cracked the code, and I figured out such a complicated situation. Only now, while writing this article, did I realized that it was far over-complicated. All the simplifications from the previous section above were done during the process of writing.

I wrote this code months ago. Why didn’t I notice these over-complications until writing this article?

Even the “simplified” code was overkill

Basically, I wrote all this, but even the simplified version wasn’t needed. That outer macro K3_K3TCHUP_EXEC_PACKET_ itself could just be a function template, and that obviates all these issues. No need to wrap the contents of K3_K3TCHUP_EXEC_PACKET_ in an immediately invoked generic lambda if it’s not a macro at all. Missing the forest for the trees.

This is what I ultimately used instead.

template <class F>
void exec_packet(F packet) {
    if constexpr (std::invocable<F>) {
        (packet)();
    } else if constexpr (std::invocable<F, state&>) {
        K3_K3TCHUP_EXEC_PACKET_STATEFUL_(packet);
    } else {
        static_assert(false);
    }
}

Way simpler than before, and I can just use the previous easier definition of K3_K3TCHUP_EXEC_PACKET_STATEFUL_ that I wanted anyway. Now, if constexpr works properly, as does the static_assert, since we’re always in a dependent context.

Is there a take home message?

I’m not sure.

Writing this article has just reinforced a belief I already had. Putting my thoughts to words, and trying to break it down enough to explain in an article, causes more clarity of thought and simplification of problems.

Amusingly, the removal of the overly complex code is immediately after the introduction of the code itself. I didn’t squash these commits because I had plans to come back and write an article on the code I wrote. So maybe the lesson is, keep old code you enjoyed writing because you’ll want to remember it later. Maybe?

Either way, I hope this was an amusing enough read and worth your while.