Is the section on “Comma Fold” (right after the recursion section) not what you are looking for?

https://www.scs.stanford.edu/~dm/blog/param-pack.html#comma-...

You mean way after he introduced the bad way of doing things? Looks like an afterthought.

My 2 cents: it's a bad idea because it's hard to test / debug.

C++ template / overload resolution involves some very convoluted logic. And it can take some work to even notice if / how it went differently than a programmer expected.

Programmers typically have logging, interactive debugging, etc. to investigate complicated algorithms like this. But (almost?) no C++ compiler provides such tooling for investigating the behavior of this algorithm.

IMHO it's an area where C++ tooling could serious use improvement.

You have static_assert for testing/debugging. The lovely thing about compile-time programming is you don't even need a separate test stage; the compiler runs your tests (asserts) for you. Then if the code builds you know it's correct.

This pattern is getting easier and easier in modern C++ as more and more thing are made constexpr.

Yes! I never thought of it that way, but imagine having a real nice IDE with a "compilation debugger", showing all these things unfolding in real-time as you change a function.

This is why the C preprocessor is superior to templates: gcc's "-E" option will show you the preprocessed source file. (I think clang also?)

My personal theory is that compiler authors have not provided a template equivalent, because they are embarrassed about the code that's being produced.

(If you disagree, prove me wrong!)

cppinsights.io shows expanded function templates as explicit specializations. It's built on LLVM, but I don't think that this tool is upstreamed.

https://cppinsights.io/lnk?code=dm9pZCBmb28oYXV0bykge30KCnZv...

Thank you! This is exactly the sort of thing I was looking for.

I found the source at https://github.com/andreasfertig/cppinsights

> prove me wrong

Template don't "produce code". They get expanded well after parsing. There is no code to be embarrassed for.

Also you can ask GCC to dump any intermediate state: https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html.

Is there a specific "-fdump" that you recommend?

There is in fact a whole section on comma folds.

Aside from the fact that the articles shows many use cases where packs and fold expressions obviate the need for recursion, what's so bad about recursive template instantiations?

If you can use a comma fold instead of recursion, please do. They are a small hurdle to learn and, after that, much easier to follow.

Obviously there's a whole section on comma folds that you didn't read. However, more importantly, there are things that you can't do without recursion. For example, how would you implement the `index_string` function in the section on recursing over template parameters without using recursion?

You don't need recursion, but you do need a template, AFAIK.

https://godbolt.org/z/o53o53W5r

Why does the

  <size_t ...Idxs>

construct work, when we needed same_as<char>?

Context. I assume you mean something like `void foo(size_t ...Idxs)`, which indeed doesn't work. It can't work, as nothing indicates that this would be a template, and it should be at least templated on the size of the pack.

<size_t ...Idxs> works because it introduces a pack that is a template parameter, so it naturally gets templated on the size of the pack (as well as on the values).

I guess an other historical issue for the grammar is that without the parameter name, `void foo(size_t ...)` is already valid grammar, and is equivalent to `void foo(size_t, ...)`, a C-style variadic.

There is zero need for template recursion here, or even templates at all.

The functionality can be computed as a simple constexpr function.

A string as a char template parameter pack is a textbook example of an antipattern.

Actually not. Try to implement a compile-time initialized const char* that represents some compile-time value like sizeof(X) for some data structure X. You'll see that you need recursion.

A place where this kind of pattern is useful is in having a generic accessor type for fields, and wanting to extend it to tuples. So for example accessor(x) might return x.field, and accessor.name might be "field." To make it work for tuples, you need a string for every possible tuple index. E.g.:

  template<typename T, size_t N> struct tuple_accessor;
  template<typename...T, size_t N>
  struct tuple_accessor<std::tuple<T...>, N> {
    constexpr decltype(auto) operator(auto &&t) const {
      return get<N>(std::forward<decltype(t)>(t));
    }
    static constexpr const char *name = index_string<N>();
  };

for demonstration purposes only.

  #include <array>
  #include <tuple>

  constexpr std::array<char, 11> itos(unsigned n) {
      std::array<char, 11> s;
      unsigned i = 0;
      while (n) {
          s[i++] = '0' + (n % 10);
          n /= 10;
      }
      s[i] = '\0';
      return s;
  }
  template<auto V>
  struct static_value {
      static constexpr auto value = V;
  };

  template<class T, unsigned N>
  struct tuple_accessor;
  
  template<class...T, unsigned N>
  struct tuple_accessor<std::tuple<T...>, N> {
      static constexpr const char *name = static_value<itos(N)>::value.data();
  };

Your constexpr function is not legal because it doesn't initialize all the array elements, even though the compiler might let you get away with it. That's easily fixed. More importantly, though, your static_value::value is not a const char *.

That restriction was lifted in 2020.

tuple_accessor::name is a const char* which is what you asked for. static_value here is an implementation detail and the type of its members is irrelevant.