It's been ages since I've done metaprogramming with C++. I had to look this up, since my first reaction was: just use recursion! Yeah, I can see why a for-loop is the preferred way to go here.

Turns out that const-call depth is limited to 512, but by implementation, not by the standard (which is undefined).

https://stackoverflow.com/a/9320911/713831

There's a way to "iterate" over parameter packs called fold expressions, but they're painful and look very weird.

I don't find them painful, but they're definitely extremely weird looking. The fact that they're "fold expressions" but are normally used with operator comma to sequence together things that want to be statements is a pretty strong sign that something went wrong in the design process.

When I first touched this around C++14 or so, I used recursion. It resulted in even worse code.

Pretty please.

    [&]<std::size_t... I>(std::index_sequence<I...>) {
      (SetupInput<I>(options, transport_manager, subscriber_queues[I], thread_pool, templated_topic_to_runtime_topic),
       ...);
    }(std::make_index_sequence<INPUT_COUNT>());

would be a lot more readible as

    for constexpr( size_t I = 0; I < INPUT_COUNT; I++ )
      SetupInput<I>(options, transport_manager, subscriber_queues[I], thread_pool, templated_topic_to_runtime_topic);
    }

Yes, there's some syntax snags around it (right now I looks mutable, something like `for (constexpr size_t I : INPUT_COUNT)` might be better), but there has to be some sane middleground.

P1061 is in C++26 so you can instead do:

  const auto [...I] = std::make_index_sequence<INPUT_COUNT>{};
  ((SetupInput<I>(options, transport_manager, subscriber_queues[I], thread_pool, templated_topic_to_runtime_topic)),...);

yay!

Oh, that is nice!

That's better, yeah. I still prefer plain ole for loops, but that's much better.

> right now I looks mutable, something like `for (constexpr size_t I : INPUT_COUNT)` might be better

I thought the same, but then you lose the ability to control the increment step. For example, one might want to iterate pairwise.

Regarding syntax, you could mandate that the loop variable has to be declared `constexpr` as well, which makes it clear that it can't be modified in the loop body.

You could make a temporary or use some std::range/span helper. Double constexpr would work, too. Feels gross in the same way template template does.

If you want to iterate over the whole thing you can just use a fold expression, which arguably look cleaner than the non-compiletime ways to map over a collection like std::transform.

Arguably is doing a lot of work here, peoples eyes tend to start glazing over when I tell them it's a parameter pack fold :) I'd much rather have a loop that doesn't confuse people not familiar with the syntax.

Even with fold expressions, sometimes you need the actual index. See here https://github.com/basis-robotics/basis/blob/ca70aee6daca37c... - I did use a fold expression, but I needed the actual index in the fold expression to both do array access and to pass down into a template parameter.

Bro fold expressions are great and all but Jesus Christ the name spacing in that file. Like have you ever heard of this hidden C++ feature called `using namespace`?

Yes, and? It's much easier to remove namespaces later using `using namespaces` if it really becomes a maintenance hazard than to go through and add them all back. This is library code that was intended to be included with unknown customer code, part of the goal is to avoid namespace collisions. (The `basis::` prefixes should go, though, the entire file is inside `basis`)

> It's much easier to remove namespaces later using `using namespaces`

lol how? sed? that's not a "much easier", that's a hack. it's actually much easier to remove `using namespace` because then the compiler will catch resolution errors.

i actually didn't notice this was a header in which ok fine don't use `using namespace` but still this is java EE levels of boiler plate you've got going on;

  void SetupInput(const basis::UnitInitializeOptions &options,
                  basis::core::transport::TransportManager *transport_manager,
                  basis::core::containers::SubscriberQueueSharedPtr &subscriber_queue,
                  basis::core::threading::ThreadPool *thread_pool,
                  const std::unordered_map<std::string, std::string> &templated_topic_to_runtime_topic) {

this signature is 90% namespace resolution - i have to squint to actually find the types...

Look I agree, it could be more readable. :)

Can we have constexpr math functions like sqrt already?

Seems like since C++26, it does use constexpr https://en.cppreference.com/w/cpp/numeric/math/sqrt

My understanding is that all of the functions found in the C compatibility headers that the C++ standard defines can not be made constexpr. sqrt is among them, as are a lot of the math functions.

The compatibility can be solved with macros to toggle it on or off depending on how you're building. C++26 has constexpr sqrt.

There is a paper suggesting to replace all macro based code, due to way modules work.

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p26...

template for is proposed for 26 as part of the reflection papers.

Meanwhile, in CL/Clojure: everything is constexpr with no syntax difference. You can even do I/O at macro-expansion time.

And I say that as someone using C++17 at work, not just a smug lisp weenie.