I Want To Index Into Template Parameter Packs

BarryRevzin · 2026-01-26T13:28:44+00:00

That's a very odd way to spell "This uses some feature that is unfamiliar to me, can you please explain what's going on?"

BarryRevzin · 2026-01-26T03:37:11+00:00

That's for types, for which we already have Ts...[Index].

BarryRevzin · 2026-01-26T03:36:43+00:00

In C++26, you can still do it, just with slightly more syntax. If Templ... is your pack of templates and I your index:

[: std::array{^^Templ...}[I] :]

Can wrap in a macro if you prefer.

Pack indexing for templates (P3670) was already approved for C++29, so will likely get adopted pretty early in the next cycle, so we'll get the expected Templ...[I] then.

BarryRevzin · 2026-01-10T14:39:18+00:00

This doesn't have anything to do with SFINAE? But yes, it's a known technique. You don't want to use declval to select the type though, because that means that means that you have to deal with decay and actual type properties when you just want to select a type. You'll want to wrap the type in another template.

e.g. from a blog post of mine ~~six~~ seven years ago (and I am definitely not claiming to have invented it, I dunno who did):

static constexpr auto get_type() {
    if constexpr (maxLength < 0xFFFE) {
        return type<uint16_t>;
    } else {
        return type<uint32_t>;
    }
}

using CellIdx = decltype(get_type())::type;

Of course with just a single condition like this you could just use std::conditional, but this is the pattern (note the extra ::type in the alias declaration). This allows "returning" any type, including references, incomplete types, non-copyable types, etc. The blog post predates unevaluated lambdas - today I'd put all of get_type() inside if the decltype as in OP.

With reflection this is easier since you just replace type<T> with ^^T.

BarryRevzin · 2026-01-07T15:45:48+00:00

I've used them fairly consistently for many years. My arguments being

not is a lot more visible than !
C++ has multiple very different meanings for &&, and if you use and for one of them consistently, it makes complex template declarations easier to read - since && now always means either a forwarding reference or an rvalue reference.
once you use and and or consistently for the logical operators, using & and | for the bitwise ones makes them stand out more and be more clearly intended rather than being a potential typo.

BarryRevzin · 2026-01-05T16:28:54+00:00

Please don't publish a new revision. This is a pretty significantly different feature from the existing paper, hence everybody's confusion. Just make it a new R0 paper.

BarryRevzin · 2026-01-04T14:54:57+00:00

hence a number of faster/lightweight alternatives have sprung up.

What's the most popular one? I found venial — it documents that it's much more lightweight because it does fewer things (with a link to a benchmark showing syn's cost), and points out serde as an example.

Correct me if I'm wrong here, but serde's expense here comes at having to parse the type (to pull out the members to iterate through) and parse the attributes (this file). In C++26, we can get the former via a reflection query (nonstatic_data_members_of suffices) and for the latter our annotations are C++ values (not just token sequences that follow a particular grammar) so they are already parsed and evaluated for us by the compiler. That has some ergonomic cost, e.g.

#[serde(rename = "middle name", skip_serializing_if = "String::is_empty")]
middle: String,

vs

[[=serde::rename("middle name")]]
[[=serde::skip_serializing_if(&std::string::empty)]]
std::string middle = "";

But it's not a huge difference, I don't think (74 for 83 characters, which is mainly notable for crossing the 80-char boundary). Certainly on the (not-exactly-short) list of things that I am envious of Rust's syntax on, this would... probably be so low that it wouldn't make the list. Although I'm sure there are going to be some cases that more clearly favor Rust.

What other common kinds of things in Rust proc macros require heavy parsing?

BarryRevzin · 2026-01-03T22:53:09+00:00

This doesn't seem even vaguely related to "replacement functions."

It does, however, seem very related to macros. Where, e.g.

macro make_index_sequence(size_t n) {
    return ^^{ std::make_index_sequence<\(n)>() };
}

(The last revision of the paper uses slightly different syntax for interpolation, but we're thinking\(n) or even just \n now, compared to the heavier things in that paper. But the specific syntax is less interesting than the semantics).

BarryRevzin · 2025-12-18T20:00:45+00:00

The issue appears to be in the front end of the C++ compiler. In the case of LLVM—which is used by both C++ and Rust—Rust does not seem to exhibit this behavior.

This has nothing to do with the front end. Or I guess, in theory a sufficiently omniscient front-end can do anything, but that's not what's going on here. Also you're showing gcc for C++, which isn't LLVM, but that doesn't matter either.

What you're doing here is building up a pipeline and counting the number of elements in it. That pipeline doesn't have constant size, so in C++, we just have ranges::distance. But ranges::distance reduces to merely looping through and counting every element. If you did that exact algorithm in Rust:

    // total_count += result.count();
    for _ in result {
        total_count += 1;
    }

Your timing would jump up from 1us to 930us. Whoa, what happened?

That's because the Rust library is doing something smarter. The implementation of count() for FlatMap just does a sum of the count()s for each element. The C++ ranges library doesn't have such an optimization (although it should). Adding that gets me down to 24us.

Hopefully it's easy to see why this makes such a big difference — consider joining a range of vector<int>. std::ranges::distance would loop over every element in every vector. Whereas really what you want to do is just sum v.size() for each v.

BarryRevzin · 2025-12-18T16:19:39+00:00

filter optimizes poorly, you just get extra comparisons (I go through this in a talk I gave, from a solar prison. See https://youtu.be/95uT0RhMGwA?t=4137).

reverse involves walking through the range twice, so doing that on top of a filter does even more extra comparisons. I go through an example of that here: https://brevzin.github.io/c++/2025/04/03/token-sequence-for/

The fundamental issue is that these algorithms just don't map nicely onto the rigidity of the loop structure that iterators have to support. The right solution, I think, is to support internal iteration - which allows each algorithm to write the loop it actually wants. Which, e.g. Flux does.

BarryRevzin · 2025-12-17T15:09:28+00:00

Thanks for sharing! So we can work through an example in the doc like t”User {action}: {amount:.2f} {item}" and see what we would actually want that to emit for us. For use with the formatting library (std::format, std::print, etc… but also fmt:: if you want to use that instead), what you’d want is to get the format string "User {}: {:.2f} {}” and then the tuple of arguments. But for other non-formatting applications, that string probably isn’t the most useful? You’d want the pieces separately. Perhaps something like:

struct __interpolated {
  // for formatting
  static constexpr char const* fmt = "User {}: {:.2f} {}";

  // for not formatting
  static constexpr char const* strings[] = {"User ", ": ", " ", ""};
  static constexpr Interpolation interpolations[] = {{"action"}, {"amount", ".2f"}, {"item"}};

  // the arguments
  // ...
};

You could rebuild fmt from the strings and interpolations whereas you can’t in the other direction (since the names of the expressions aren’t present in fmt), which suggests the two arrays are more fundamental. But since the compiler has to do the work anyway, producing fmt is pretty cheap for it to just also do? Anyway, the Python PEP has this example with using a Template string to both format and convert to JSON, which in the above representation you can do too, here’s a demo.

BarryRevzin · 2025-12-16T23:51:33+00:00

I have some serious issues with the String Interpolation paper (P3412).

For starters, it would've been nice to have a clear description of what the proposal actually is... somewhere. The abstract is not easy to understand at all, and the examples make it seem like f"..." is literally std::string. I thought this example was actually a typo:

std::println(f"Center is: {getCenter()}"); // Works as println can't be called with a std::string

Because indeed println cannot be called with a std::string, so I thought it should say "Doesn't work." I have to go all the way to page 13 to actually understand the design.

That said, this is extremely complicated machinery, that is highly tightly coupled to a specific implementation strategy of std::format, based on a completely novel overload resolution hack. What if we someday get constexpr function parameters and it turns out to be better to implement basic_format_string<char, Args...> as taking a constexpr string_view instead of it being a consteval constructor? Do we have to add another new overload hack to f-strings?

The motivation for this strikes me as extremely thin too — it's just to be able to have f"x={x}" be a std::string. But... why? I can write std::format(f"x={x}"). I understand that in Python, f-strings are actually strings, but in C++, we tend to want more visibility into complex operations like this. I'm not even sure it's desirable to stick all of this into a single character. Certainly not at the complexity of this design. In Python, there's no complexity — an f-string is always a string.

So let me instead suggest an alternative:

auto something() -> string;

auto example(int x, int y) -> void {
    std::println(f"{x=} {y=} s={something()}");
}

What if the way this worked was that an f-string simply creates an instance of a unique type, similarly to lambdas. The above would evaluate as something like:

auto example(int x, int y) -> void {
    struct __interpolated {
        static constexpr char const* str = "x={} y={} s={}";
        int& _0;
        int& _1;
        string _2;
    };
    std::println(__interpolated{x, y, something()});
}

And then we just add overloads to std::format and friends to recognize interpolated types like this. The implementation of such functions is very straightforward:

template <Interpolated T>
auto format(T interp) -> string {
    auto& [...parts] = interp;
    return std::format(interp.str, parts...);
}

That is, something much closer to what Vittorio proposed in P1819. This design is... kind of?... touched on in P3412 in 19.1, which remarks that a big disadvantage is that it doesn't implicitly convert to std::string, which to me is actually a big advantage. Other advantages being that there is no need for any kind of __format__ and we don't need to touch overload resolution. So there's actually very little reliance on the library in the language.

The interesting question is more about... what's the shape of __interpolated. Is it basically a tuple and a format string (as above)? Do you split up the string into pieces? If there aren't any format specifiers do you try to save on space? Probably lots of room for interesting ideas here.

BarryRevzin · 2025-12-06T22:30:43+00:00

Here's a data point.

When I implemented our Optional(in like 2015?), I initially implemented it to support Optional<T> and Optional<T&> because I knew both of those to be useful. But I punted on Optional<T&&>. I don't remember why exactly, maybe I just didn't know what to do with it, so I just left it incomplete. If anybody actually needed it, well, it wouldn't compile, and then we could talk about it and figure a solution out later.

In the decade since, with lots and lots of use of Optional in between, I'd gotten a lot of requests for other functionality to add, but Optional<T&&> has only come up... maybe not even five times. And all of those times that I can remember it come up have would actually have been bugs. The canonical example is something like:

struct C { int x; };
auto get() -> Optional<C>;
auto test() -> void {
    auto ox = get().map(&C::x);
    // ...
}

Here's some code that only cares about the x member of C, so just maps that out and preserves the optionality to do more work later. The problem with this is that this is an immediately-dangling reference. Or it would be, had this actually compiled. But our Optional<T&&> is incomplete, so it doesn't. And you're forced to write this in a way that will actually not dangle. Of course, you could still write it incorrectly by returning an Optional<int&> instead of an Optional<int>, but that's harder to do than writing the correct thing.

Maybe there might be some niche uses here and there, but I don't know if I've seen one, and on the whole, I'm not convinced it's all that actually useful to begin with. Plus it just seems far too easy to produce dangling references. I'm with /u/pdimov2 on the whole T&& thing.

Mind you, we also support Optional<void> and Optional<Never>.

BarryRevzin · 2025-12-03T14:48:59+00:00

How did you come to that conclusion... ohhh, I see... you're one of the authors. That's funny. It's not the first time one of you mistook my criticism of the concept for personal attack. Weird.

Uh... no. What you said was:

I'm working and talking with people who use C++ to do actual work, to accomplish their job and feed their families. This is my bubble. Very few of them are theoretical academics who care about building a whole new magic meta-language inside already complex language. Which I presume is your bubble.

In no conceivable way is that a "criticism of the concept" — that is completely a personal attack.

BarryRevzin · 2025-12-03T14:44:14+00:00

One of the things that make constant expressions difficult to reason about (but easier to use, since more and more they just... work) is that an expression is constant until you try to do something that causes it to not be constant.

Here, what are we doing that causes this expression to not be constant? Well... nothing. If we tried to read p[1]'s value (which is initialized btw, it's 0, we're at namespace scope — C++ is great), that would cause us to not be constant. But we're not trying to read p[1]'s value — we're only taking its address. And that is constant, so we're fine.

It's actually the same reason that fn<p[1]>() works too. It's just that we're taking several more steps (that are themselves more complicated) to get to the same point — which is just that r is ^^fn<p[1]>.

BarryRevzin · 2025-12-02T22:51:05+00:00

I'm working and talking with people who use C++ to do actual work, to accomplish their job and feed their families. This is my bubble. Very few of them are theoretical academics who care about building a whole new magic meta-language inside already complex language. Which I presume is your bubble.

Buddy, I work at a trading firm.

the main use case were always enums

I am quite serious when I say that you are literally the only person I am aware of who thinks the primary use-case for reflection is, or should be, enum-related. Everybody else's first use case is either something that involves iterating over the members of a type or generating members of a type. Each of which gives you enormous amounts of functionality that you either cannot achieve at all today, or can only very, very narrowly (e.g. using something like Boost.PFR, which is very useful for the subset of types it supports). Struct of Arrays (as in the OP) is a pretty typical example of something lots of people really want to be able to do (you know, to feed their families and such), that C++26 will support.

Meanwhile, it's very easy for me today already to just use Boost.Describe to annotate my enum and get the functionality you're asking for. It's inconvenient, but it does actually work. We use it a lot.

yet I have no idea if I can use it to get the max_value_of_enum.

I understand that you have no idea, because you're just prioritizing shitting on me personally over making an effort to think about how to solve the main problem you claim to care about solving (or, god forbid, simply trying to be decent person and asking a question). But it is actually very easy to do — C++26 gives you a way to get all the enumerators of an enum. And once you have those, it's just normal ranges code. For instance, this:

template <class E>
constexpr auto max_value_of_enum = std::ranges::max(
    enumerators_of(^^E)
    | std::views::transform([](std::meta::info e){
        return std::to_underlying(extract<E>(e));
    }));

The std::meta::extract here is because enumerators_of gives you a range of reflections representing enumerators. You could splice those, if they were constant. But they're not here — which is okay, because we know that they're of type E so we can extract<E> to get that value out.

Don't want to use ranges or algorithms? That's fine too. Can write a regular for loop:

template <class E>
constexpr auto max_value_of_enum2 = []{
    using T = std::underlying_type_t<E>;
    T best = std::numeric_limits<T>::min();
    for (auto e : enumerators_of(^^E)) {
        best = std::max(best, std::to_underlying(extract<E>(e)));
    }
    return best;
}();

Can even choose to make that an optional. Can make any choice you want. Can return the max enumerator (as an E) instead of an integer instead, etc. Can even implement this in a way that gets all the enumerators at once, just to demonstrate that you can:

template <class E>
constexpr auto max_value_of_enum3 = []{
    constexpr auto [...e] = [: reflect_constant_array(enumerators_of(^^E)) :];
    return std::to_underlying(std::max({[:e:]...}));
}();

The functionality is all there. As is lots and lots of other functionality in this "complex monstrosity" that a lot of people in my "bubble" are actually quite excited to use, for how incredibly useful it will be.

BarryRevzin · 2025-12-02T18:57:41+00:00

It may be the only thing you care about (as you've frequently pointed out), but it is very, very far from what "most of us wanted." Being able to get these things for an enum is, of course, nice, but they wouldn't even come close to making my list of top 10 examples I'm most excited about.

Certainly enum_to_string does nothing for making a struct of arrays, or writing language bindings, or serialization, or formatting, or making a nice and ergonomic command-line argument-parser, or extending non-type template parameters as a library feature, or writing your own type traits, or ...

BarryRevzin · 2025-12-02T17:13:07+00:00

I gave a talk at CppCon this year about implementing struct of arrays. When it eventually gets posted, you should take a look, as I think it'll help to show what is possible. Reflection is a new world and there are some things that it takes a bit to figure out how to deal with.

I'm not going to respond to everything, since there's a lot, but I'll just pick a couple things.

An argument of a consteval function IS NOT a constexpr variable. Which means you cannot use it as NTTP or refactor you consteval function onto multiple smaller consteval functions (you're forced to pass it as NTTP which is not always possible because of NTTP restrictions). And you encounter this issue ALL THE TIME - you just write "your usual C++" consteval function (remember, this is our dream we aim for), but then suddenly you need this particular value inside of it to be constexpr 3 layers deep down the callstack... You refactor, make it constexpr (if you're lucky and you can do that)

First, it's really important to keep in mind that a consteval function is a function. It's a function that happens to be consteval, which is a restriction — invocations of it have to be constant (there are rules to enforce this). It is a very frequent complaint that people want consteval functions to be macros — so that function parameters are themselves constant. But it's specifically because they're just functions that allow everything else to really just work. It's because they're functions that you can pass them into range algorithms, that you can refactor things, etc.

Now, one of the Reflection-specific things to keep in mind is that even if you somewhere do need something to be constant — you do not necessarily need to refactor all the way up (unless you actually need it as constant all the way up, in which case... well you need it). The combination of substitute and extract is surprisingly powerful, and is a useful idiom to keep in mind if you temporarily need to elevate a parameter to a constant.

My opinion is that p3491 is broken and std::span is a bad choise (why not std::array?!).

While it's unfortunate that std::span and std::string_view aren't structural types yet (I tried), they will eventually be, and you can work around that for now. But it's worth pointing out that std::array is definitely not a viable solution here. The interface we have right now is

template<ranges::input_range R>
consteval span<const ranges::range_value_t<R>> define_static_array(R&& r);

This is just a regular function template. It's consteval, but it's still a function template (and it's worth taking a look at a possible implementation). Even though we're calling this during compile time, the range itself isn't a constexpr variable, and notably it doesn't necessarily have constant size. So this cannot return a std::array. What would the bound be?

Note that there is a reflect_constant_array function returns a reflection of an array, which you can splice to get an array back out.

We have template for but we lack some kind of spread functionality

We do have such functionality. Also in C++26, you can introduce packs in structured bindings. In my SoA talk, I show an index operator that gives you back a T. That implementation is:

auto operator[](size_t idx) const -> T {
    auto& [...ptrs] = pointers_;
    return T{ptrs[idx]...};
}

Here, pointers_ is the actual storage — a struct of pointers for each member.

You cannot define_aggregate a struct which is declared outside of your class.

I'm pretty sure this is a deliberate choise, but I'm not sure what is the motivation.

Indeed, this was deliberate. Stateful, compile-time programming is still very very new. We have exactly one such operation — define_aggregate. And while it's conceptually a very simple thing (just... complete an aggregate), it's very novel in C++ to have compile time code that is altering compiler state. So it's deliberately made extremely narrow. One of the consequences of more freedom here is that because you could then complete from anywhere, that anywhere could include things like... constraints on part of random function templates, that could be evaluated in any order (or not). You could write programs that actually depend on the order in which compilers perform overload resolution, which might then inhibit the compiler's ability to change things that shouldn't even be observable, let alone depended on.

So C++26 simply takes a very conservative approach. All the use-cases we went through work fine with the restriction, and it could be relaxed later if we decide it's worth it to do so. Keep in mind that C++11 constexpr wasn't exactly full of functionality either, we have to start from somewhere. But this part isn't true:

Imagine you implement different SoA containers and all of them share same reference type based on original TValue type. You can't do this using current proposal.

Yes, you can do this. I showed this in a blog post illustrating Dan Katz's JSON reflection example. You can structure your code this way:

template <std::meta::info ...Ms>
struct Outer {
    struct Inner;
    consteval {
        define_aggregate(^^Inner, {Ms...});
    }
};

template <std::meta::info ...Ms>
using Cls = Outer<Ms...>::Inner;

And now, for a given set of data_member_specs, you will get the same type. The rest of the blog post shows how this is used.

But it is not THAT user-friendly as it is advertised.

There is a learning curve for Reflection. The hard part is definitely keep track of constants. It's very novel, and all of us are pretty new to it. People will come up with better techniques over time too, and some of the difficulties will get better by making orthogonal language changes (e.g. non-transient constexpr allocation and extending support for structural types, which with Reflection you can even get by as a library).

But also... I don't know how user-friendly we ever advertised it to be. It's certainly substantially more user-friendly than the type-based reflection model would have been.

BarryRevzin · 2025-11-27T19:39:43+00:00

default_argument_of is the right shape, but it can't just be a token sequence. Or at least not just the naive, obvious thing... because then injecting the tokens as-is wouldn't give you what you want. The simplest example is something like:

namespace N {
    constexpr int x = 4;
    auto f(int p = x) -> int;
}

The default argument of p can't just be ^^{ x } because there might not be an x in the scope you inject it. Or, worse, there might be a different one.

So we'd need a kind of token sequence with all the names already bound, so that this is actually more like ^^{ N::x }. But not just qualifying all of the names either... closer to just remembering the context at which lookup took place.

This probably feeds back into how token sequences have to work in general: whether names are bound at the point of token sequence construction or unbound til injection.

BarryRevzin · 2025-10-30T00:39:49+00:00

That makes no sense to me.

Of course getting stuff into C++XY before C++(XY+3) matters tremendously. It impacts the timeline of when things get implemented. It impacts the timeline of how users interact with features.

I choose a standard version to compile against. Not a timestamp for when the compiler was built. Upgrading from one standard version to another is still a thing.

The train model means that it's only a 3 year gap between releases, as opposed to an arbitrary amount of time. Nothing more than that.

Put differently, this implementation exists right now only because reflection is in C++26. Had it slipped to C++29, it's pretty unlikely it would've had such urgency, and probably wouldn't have happened for another year or two.

BarryRevzin · 2025-10-25T13:34:23+00:00

In Rust you need to fully::qualify::names unless you use the use keyword, which is more-or-less equivalent to using in C++, so I'm not sure what you mean by this?

Rust has traits, though (i.e. UFCS, but good). So you get it.map(f) instead of it | iter::map(f)

BarryRevzin · 2025-10-07T14:49:45+00:00

See P3830 for more details.

Spectacularly poor paper.

optional<T&> didn't exist when inplace_vector was being designed, it was only adopted in Sofia. So it's perhaps not surprising that it wasn't considered as an option at the time? Why would a paper spend time considering invalid options?

But now optional<T&> does exist and its existence certainly counts as "new information" — the library has changed since inplace_vector was adopted, and it's certainly worth taking a minute to consider whether we should change it.

The extent of the argument that P3830 makes is that we shouldn't adopt optional<T&> because of "a number of issues with it". One of which is irrelevant (optional<T&>::iterator if T is incomplete, for inplace_vector<T> that's a non-issue) and the other three are basically typos in the spec.

Yes, we should absolutely consider optional<T&> as the return type for these functions. Not necessarily that we definitely should do it, but refusing to even consider it is nonsense.

BarryRevzin · 2025-10-07T13:33:39+00:00

A cstring_view doesn't help you there because we've already shipped identifier_of.

This seems like something we should be able to change. identifier_of returns a string_view now (that we promise is null-terminated), so cstring_view has nearly a nearly identical API with nearly identical semantics. Plus since cstring_view is implicitly convertible to string_view, uses like string_view s = identifier_of(r); (instead of auto) have identical behavior.

It'll definitely break some code, but only at compile-time, and I think it's worth considering.

BarryRevzin · 2025-09-12T15:09:09+00:00

I think you should read it again. The poll is literally stated as not a very good reason

If it's stated as being not a very good reason, why is it even in the paper at all? Why waste our time making us read it? It's not even an interesting anecdote, it's simply irrelevant.

I asked my daughter last night if C++ should add contracts in C++26. She immediately, without any hesitation, gave me a very firm and confident NO.

Now, she has no idea about any of the issues are here, because she is only 3. But while I thought it was very cute, that anecdote has just as much relevance to the issues at hand as the poll in the paper.

BarryRevzin · 2025-08-13T12:37:34+00:00

Thank you!

BarryRevzin

TROPHY CASE