Pack Indexing and Constexpr Indices

[WotJProject]

I've been exploring pack indexing in C++26, and was curious about why the index must be a constant expression (not even a const value is accepted). If you write a variadic/recursive statement, load the pack into an array, or otherwise use a more verbose (and possibly expensive) workaround, you can get the exact same functionality. Parameter packs are just that- parameters, so why can't we access members of the pack more easily?

EDIT: Added a fourth and fith methods. The fourth is probably the simplest and most performant under general circumstances.
Please see comments below for further examples, including a variable-type version with compile-time type information.

Here's some example code of variadic addition functions:

1. Using my desired usage of pack indexing (which will not compile)
2. Using variadic recursion
3. By copying into an array first
4. Passing pointers for pack elements into an array first and dereferencing them during the loop
5. Using a switch statement and if constexpr to estimate the typical size, only using a buffer for larger packs.

(tested with GCC (trunk), in both -O0 and -O3.)

#include <cstdio>

constexpr int packIndex(const auto... inputs) noexcept {
    int output = 0;
    for(int i = 0; i < sizeof...(inputs); i++){
        output += inputs...[i];
    }
    return output;
}


constexpr int varRecursive(const int input) noexcept {
    return input;
}
template<typename... reType>
constexpr int varRecursive(const int input, const reType... reInput) noexcept {
    return input + varRecursive(reInput...);
}


constexpr int packArray(const auto... inputs) noexcept{
    int arr[sizeof...(inputs)]{inputs...};
    int output = 0;

    for(std::size_t i = 0; i < sizeof...(inputs); i++){
        output += arr[i];
    }

    return output;
}

constexpr int packptr(auto... inputs) noexcept {
    int* pack[sizeof...(inputs)]{&inputs...};

    for(int i = 1; i < sizeof...(inputs); i++){
        *pack[0]+=*pack[i];
    }

    return *pack[0];
}


constexpr int ifConstSwitch(const auto... inputs) noexcept {
	int output = 0;
	constexpr auto size = sizeof...(inputs);

	for(int i = 0; i < size; i++){
		switch(i){
			case 0:{
				if constexpr(size>0) {
					output += inputs...[0];
					break;
				}
				else return 0;
			}
			case 1:{
				if constexpr(size>1) {
					output += inputs...[1];
				}
				break;
			}
			case 2:{
				if constexpr (size>2) {
					output += inputs...[2];
				}
				break;
			}
			case 3:{
				if constexpr(size>3) {
					output += inputs...[3];
				}
				break;
			}
			case 4:{
				if constexpr(size>4) {
					output += inputs...[4];
				}
				break;
			}
			case 5:{
				if constexpr (size>5) {
					output += inputs...[5];
				}
				break;
			}
			default:{
                if constexpr (size>6) {
				    static int buf[size]{inputs...};
				    output += buf[i];
                }

				break;
			}
		}
	}
	return output;
}


int main(){
    //why do these work...
    std::printf("\nrecursive: %d", varRecursive(10,10,10));
    std::printf("\npack array: %d", packArray(10,10,10));
    std::printf("\npointer array: %d", packptr(10,10,10));

    std::printf("\nsmall if-constexpr indexing: %d", ifConstSwitch(10,10,10));
    std::printf("\nlarge if-constexpr indexing: %d", ifConstSwitch(10,10,10,10,10,10,10,10,10,10));


    //but this does not?
    std::printf("\npack indexing: %d", packIndex(10,10,10));
    

    return 0;
}

[LB--]

Because there's a major difference. Your parameter packs are not forced to be homogeneous, the types can differ from one parameter to the next. Putting them in an array forces them to all be the same type, and could also confuse the optimizer into including unused values in the final generated binary depending on how well it can see through what you're doing.

[WotJProject]

Yes, I'm trying to figure out the specific reason for it being a constant expression. The vague idea that "there's something in the standard" doesn't really explain anything. I've looked over the spec- pack indexing is totally new, there are no hereditary concerns except for the previous syntax for indexing into an array that was passed using parameter packs, which has now been deprecated(rather, slightly altered) in favor of pack indexing.

The reason I've been demonstrating all these things and going on about optimization is because if this is handled at the language level, there doesn't need to be any optimizations at all. In the same way that the pack operator works to begin with, so too will indexing work behind the scenes at the compiler level. The language is different from the STL- wherein the STL has to be written in the language and obey its rules, the language itself is basically the rules for turning the code we write into instructions for the hardware or OS. I've said this multiple times now, but that's a big advantage to something being a language feature vs. something we implement ourselves.

And also something I've said multiple times, using an inline array of any kind would result in some kind of copy at lower optimizations- either copying the pack elements themselves, or their addresses. While this is trivial in many cases, it's still a wasteful thing that can potentially cause problems in more delicate situations, not to mention the added complexity of tracking the types if multiple types are used. My examples here I've ensured get optimized away just to demonstrate how the assembly would work if it were implemented in the language itself.

As I said before, I'm simply proving that it is trivially possible with how the language works today, and there are no barriers to implementing this system at all, in any way, in any part of the language specification. If there are, I'd like to see them, because it's something I'm missing!

I guess the bottom line here is, if I can generate very simple assembly to index the pack without using a constant expression, what, specifically, is stopping them from doing that in the language itself?

[LB--]

You did not answer my question, I am not sure if you even understand what I am asking about. My question was this:

You suggested the compiler could, in your example, unroll the loop and turn the runtime value into constant expressions as a result of being able to perform that optimization. I'm asking you where that ends, at what level of complexity is the compiler allowed to say "no, I can't figure out a way to do this at compile time for you, you have to change your code structure"? How do you define that boundary?

Let's take a look at it in the context of your original code:

constexpr int packIndex(const auto... inputs) noexcept {
    int output = 0;
    for(int i = 0; i < sizeof...(inputs); i++){
        output += inputs...[i];
    }
    return output;
}

Here, you rightly see an obvious transformation the compiler could perform - loop unrolling - so that the expression inputs...[i] can magically become a constant expression. But do you only want it to work in this very specific scenario with a for loop structured in exactly this way, or do you want it to also allow slight tweaks like this?

constexpr int packIndex(int start, int end, const auto... inputs) noexcept {
    int output = 0;
    for(int i = start; i < sizeof...(inputs) && i < end; i++){
        output += inputs...[i];
    }
    return output;
}

Here, the range of the loop is affected by passed in parameters, which might only be known at runtime. The compiler could still find a way to generate an unrolled loop with a dynamic jump past the skipped start and branches to jump past the skipped end, but that is an increase in complexity for both the compiler and the standard, and it's a non-obvious way in which additional runtime cost is incurred. How would the upper bounds on the allowed runtime cost even be specified?

My point is, you can keep making tweaks that increase the complexity of the required transformation endlessly, so where do you think it should end? At some point you will find a way to write code in a way to force the compiler to solve unsolved problems in math. There is no way that will ever be standardized.

[WotJProject]

I didn't answer because it's not at all related to what I'm asking, and I try to keep discussions relatively on-task.
But, if you really want to know, I'd do it similar to how constexpr arrays are indexed; that is, the indexing is optimized away at compile time and the referenced object/data is inlined. If it cannot be deduced, the compiler will throw an error. How much complication and which patterns to support would be implementation-defined, as such things often are. The base requirement is simply that I can iterate over the pack. All other details are secondary.

In any case, there will be no runtime cost, because as I'm so fond of saying, this should all be a compile-time operation. Even most of my examples here have had zero additional runtime cost at -O3. I'm not even sure what your 2nd example is getting at; taking a slice of the pack is a completely separate and tertiary concern. I would assume it wouldn't be any more trouble to do something like that, any more than it would for a constexpr array, but again this is too far apart from my original question.

So to get back on track, I think you're getting caught up in the minutia of my examples, when that's not what their purpose is. I'm not making a formal proposal to the committee, I'm trying to figure out why the conscious decision was made to restrict the indices. I don't really care how I would do it, or really how anyone would do it- the specifics are irrelevant. I just wanted to prove it was trivially possible, which I did. I've done it 6 different ways in this conversation alone, plus one more abomination I made with macros that I'll save you the trauma of reading, and another I half-heartedly experimented with that passed in the parameters as a std::tuple pack, which more or less functioned like my CTTI example with extra overhead. No matter how I approach it, I can't understand why the decision was made.

[LB--]

I guess we are somehow both misunderstanding each other and/or talking past each other.

As I've said multiple times now, pack indexing requires a constant expression because each element of the pack can have a different type. That is the full entire reason. Everything you've done and shown is just your ideas for what could be done to work around that problem, and as you've seen, there's a lot of variety in how it can work, so that would have been more complicated to standardize. Better to get some form of pack indexing than to not have it for a decade while all the additional complexities are worked out.

[WotJProject]

I think we're just looking at the problem in different ways, which is fine. It's good to get different perspectives.

I disagree that's the reason though, because this isn't actually an array. Parameters are not (so far as I can remember, at least once you get into non-trivial types) guaranteed to be contiguous in memory, and neither are template arguments. Parameter packs are somewhere inbetween, so the pack subscript operator isn't actually a pointer offset or anything like that. That's why I was emphasizing the compile-time replacement of pack indices as the pack elements- because the type and size of each element is completely irrelevant to the indexing. All it's doing is telling the compiler "take this element from the pack and put it here", almost like a macro. Any restrictions that might arise in normal array formation or subscript dereferencing don't apply. At the end of the day, they're just parameters, just like if you explicitly typed them out instead of using packs.

My chief suspect is actually related to template arguments. Packs are part of templates and they have similar restrictions, so my guess is they just carried over those properties from the template syntax. The issue I have with that is that once you're in the function body, that property is discarded. You can do almost whatever you want to template parameters, depending on what it is, and the same is true for the pack elements themselves. It would be one thing if the index came from outside the scope, but if it's a simple for-loop, it's nonsense that they couldn't at least try to deduce it.

I wouldn't expect anything unknowable at compile time to work, and I wouldn't expect it to behave outside the syntax of a normal subscript. It's not that complicated at all, that's why I provided all these really simple examples to prove it.
I just also wouldn't expect them to add a feature that is so half-baked and useless. You've expressed concern that there are a lot of ways to implement loops that wouldn't work, that would complicate the implementation, but what about this:

int add(auto... inputs){
    return inputs...[0] + inputs...[1];
}

Since I can only use explicit constant expressions for the index, I have no way of dynamically adjusting the function body to adapt to varying pack sizes. I have to know, explicitly, exactly how many pack elements to pass in, or write a ton of overloads that defeat the entire purpose. If I tried to do add(1,2,3), it would discard 3. If I tried add(4), it wouldn't even compile. Since that's the case, using a pack only makes it harder to read, and I would have to read the function body to even know at all. It would be better to do this instead:

int add(int lhs, int rhs){
    return lhs + rhs;
}

This all sure seems like a very delicate way to do it, that presents more issues than we would see if the compiler at least attempted to deduce indices at compile time. That's what I mean when I say it's useless; what they've done is add something that doesn't really solve any problem or provide any new features, and makes use of an operator that doesn't even work like we would expect it to in any other context. Attempts to use it at all in any practical way are going to be wrought with disappointment.

All I really want out of this is to know if there's a good reason for it or not, because I can't find one. If I'm right and they just carried over template parameter restrictions, I would push for that to be corrected. Maybe I really would put a proposal together...
Though I would expect to see a constexpr for before they'd ever walk back something obscure like this.

[LB--]

I disagree that's the reason though, because this isn't actually an array.

This is a funny sentence to me, since it not being an array is the reason it requires a constant expression.

the type and size of each element is completely irrelevant to the indexing

The entire C++ language is built around static typing though. You can say that in dynamically typed languages like Python, but in C++ if you don't know the type or size of something at compile time your options are extremely limited and you have to employ workarounds like what you've shown. Having the compiler automatically transform code in various ways to make the workarounds less needed is a complicated thing to get working well, and often requires brand new syntax, as seen with the template for syntax.

Any restrictions that might arise in normal array formation or subscript dereferencing don't apply.

I agree, I am not sure where this talk about array limitations came from, arrays are just a convenient way to coerce the possibly different types into a single uniform type to make working with the elements easier. If you can't coerce things into a single uniform type, then you can't use an array, but you can still use pack indexing. It just still requires a constant expression due to the language being statically typed.

The issue I have with that is that once you're in the function body, that property is discarded.

How? The function is still a template context, it doesn't know what the count or types of the parameters are until it specifically checks.

It would be one thing if the index came from outside the scope, but if it's a simple for-loop, it's nonsense that they couldn't at least try to deduce it.

That "if the index came from outside the scope" comment is the entire problem that I have been trying to get at throughout this whole conversation. C++ has no system by which variables can be tagged as having been tainted by outside context for the purpose of distinguishing what is or isn't allowed for your proposed syntax. It would have to be worked out and standardized and implemented by compilers, just to end up needing to be expanded later. template for is much easier to get standardized by comparison.

Since I can only use explicit constant expressions for the index, I have no way of dynamically adjusting the function body to adapt to varying pack sizes.

For this particular example, you can just use fold expressions:

int add(auto... inputs){
    return (0 + ... + inputs);
}

Fold expressions already support most use cases of parameter packs, including running a block of code for each parameter in the pack:

void print(auto... inputs){
    ([](auto input){
        std::println("{}", input);
    }(inputs), ...);
}

The syntax isn't as familiar and straightforward as a for loop, but it is available and working now. What doesn't work well with fold expressions is when you need to deal with more than one element of the pack at once, that's when pack indexing has to be used:

#include <print>
#include <type_traits>

struct PrintOption
{
    bool q;
};

template<std::size_t Iterations>
void foreach(auto f)
{
    [&]<std::size_t... I>(std::index_sequence<I...> const){
        ((f(std::integral_constant<std::size_t, I>{})), ...);
    }(std::make_index_sequence<Iterations>{});
}

void print(auto... inputs){
    foreach<sizeof...(inputs)>([&]<std::size_t I>(std::integral_constant<std::size_t, I> const){
        if constexpr(!std::is_same_v<std::remove_cvref_t<decltype(inputs...[I])>, PrintOption>){
            if constexpr(I > 0){
                if constexpr(std::is_same_v<std::remove_cvref_t<decltype(inputs...[I - 1])>, PrintOption>){
                    if(inputs...[I - 1].q){
                        std::println("{:?}", inputs...[I]);
                        return;
                    }
                }
            }
            std::println("{}", inputs...[I]);
        }
    });
}

int main()
{
    print(3, "a", PrintOption{.q = true}, "b", 3.14);
}

Output: https://compiler-explorer.com/z/bxqhrodfY

3
a
"b"
3.14

Sure, you can find alternative ways to support this sort of thing without pack indexing, but it limits your options. Pack indexing lets us reach back or forward in the pack and just do what we want without workarounds.

[LB--]

Oops, I guess I clicked in the wrong reply box, my bad.

[WotJProject]

This goes back to what I was saying about the hoops we jump through working with the language, vs. what the language does to our code during compilation.
Here's the assembly for that example I gave earlier, with an int and a double at -O0:

int add(auto... inputs){
    return inputs...[0] + inputs...[1];
}

add(5,3.0);

"int add<int, double>(int, double)":
        push    rbp
        mov     rbp, rsp
        mov     DWORD PTR [rbp-4], edi
        movsd   QWORD PTR [rbp-16], xmm0
        pxor    xmm0, xmm0
        cvtsi2sd        xmm0, DWORD PTR [rbp-4]
        addsd   xmm0, QWORD PTR [rbp-16]
        cvttsd2si       eax, xmm0
        pop     rbp
        ret

You notice how both the int (edi) and double(xmm0) are copied from different registers into the same buffer and indexed using rbp? That's because at that level, the type and size don't matter. Types are a high-level concept imposed on us to make it much easier to reason about values. The language already does this sort of thing fundamentally - the parameters, even in a pack, are all already packed into a buffer as long as they're trivial types. Template parameters are pasted in almost like macros, but that means you can pass in a mutable value, as long as it has static storage duration, and change it within the function body.

Look at all the hoops you had to jump through to force the compiler to use a constant expression index. Did you see what the assembly looked like? It was atrocious; literally doing 15x more work at -O3 than what my CTTI example was doing at -O0. I certainly wouldn't want that to be the implementation! Compare that to the above assembly, where two values are stored and loaded in, what, 4 instructions?

The STL is notoriously bad when it comes to lower-level stuff like this, so I avoid type_traits and other similar libraries altogether. It's certainly not how the actual language works under the hood, they're just general tools to help people who don't need a more specific solution.

That's why I want it to be a language feature, not simply an STL workaround, or even my own local workaround. We cannot, within the language, do what it's already doing reliably under the hood. We'd have to write inline assembly and then use a macro to override the operator, which then wouldn't get optimized or anything by the compiler.

I do like your foreach solution though, I need to experiment more with lambdas. Who needs the committee? I'll make my own constexpr for...

Oops, I guess I clicked in the wrong reply box, my bad.

Yea I did that a few replies ago, and had to delete the comment and paste it back in as a reply. Not a fan of GitHub's UI either...

[LB--]

That's because at that level, the type and size don't matter. Types are a high-level concept imposed on us to make it much easier to reason about values. The language already does this sort of thing fundamentally - the parameters, even in a pack, are all already packed into a buffer as long as they're trivial types.

Actually it depends on the calling convention of the instruction set and operating system.

Template parameters are pasted in almost like macros, but that means you can pass in a mutable value, as long as it has static storage duration, and change it within the function body.

No, at optimization level 0 with most compilers they are generally treated the same as inline functions. I don't know what you're getting at.

Did you see what the assembly looked like? It was atrocious; literally doing 15x more work at -O3 than what my CTTI example was doing at -O0.

You're comparing apples to spaceships here. My example prints text to stdout, your example adds numbers. Just edit my example to add numbers instead and you'll see it produces the same assembly as yours: https://compiler-explorer.com/z/46KGrn1dc

#include <cstddef>
#include <type_traits>
#include <utility>

int accumulateV1(auto... inputs){
    return inputs...[0] + inputs...[1] + inputs...[2];
}

template<std::size_t Iterations>
void foreach(auto f)
{
    [&]<std::size_t... I>(std::index_sequence<I...> const){
        ((f(std::integral_constant<std::size_t, I>{})), ...);
    }(std::make_index_sequence<Iterations>{});
}

int accumulateV2(auto... inputs){
    int output = 0;
    foreach<sizeof...(inputs)>([&]<std::size_t I>(std::integral_constant<std::size_t, I> const){
        output += inputs...[I];
    });
    return output;
}

int show_accumulateV1()
{
    return accumulateV1(10, 10, 10);
}
int show_accumulateV2()
{
    return accumulateV2(10, 10, 10);
}

-O1:

show_accumulateV1():
        mov     eax, 30
        ret
show_accumulateV2():
        mov     eax, 30
        ret

With a tweak:

int show_accumulateV1(int a, int b, int c)
{
    return accumulateV1(a, b, c);
}
int show_accumulateV2(int a, int b, int c)
{
    return accumulateV2(a, b, c);
}

show_accumulateV1(int, int, int):
        add     edi, esi
        lea     eax, [rdi+rdx]
        ret
show_accumulateV2(int, int, int):
        add     edi, esi
        lea     eax, [rdi+rdx]
        ret

The STL is notoriously bad when it comes to lower-level stuff like this, so I avoid type_traits and other similar libraries altogether. It's certainly not how the actual language works under the hood, they're just general tools to help people who don't need a more specific solution.

Actually, type_traits is how the language works under the hood, it works completely at compile time and integrates with compiler intrinsics.

We cannot, within the language, do what it's already doing reliably under the hood.

Actually, I just showed above that we can.