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 method I figured out. Might be the best way to deal with non-trivial types without too much overhead or if variadic recursion is undesired.

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. 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 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];
					continue;
				}
				else return 0;
			}
			case 1:{
				if constexpr(size>1) {
					output += inputs...[1];
				}
				continue;
			}
			case 2:{
				if constexpr (size>2) {
					output += inputs...[2];
				}
				continue;
			}
			case 3:{
				if constexpr(size>3) {
					output += inputs...[3];
				}
				continue;
			}
			case 4:{
				if constexpr(size>4) {
					output += inputs...[4];
				}
				continue;
			}
			case 5:{
				if constexpr (size>5) {
					output += inputs...[5];
				}
				continue;
			}
			default:{
				static int buf[size]{inputs...};
				output += buf[i];

				continue;
			}
		}
	}
	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("\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]

Right but it can be indexed at all because we know, at compile time, how many there are and where they are. I'm not saying they should be implicitly converted to an array, that would be silly. I'm saying that if we can index them at all, we should be able to index them within the scope without constant expression qualification.

That's why I provided the other examples- it's very possible to do that, even at runtime, using other methods. It's not a huge bother for trivial types, but anything that's either large or has expensive constructors is a problem to reassign to an array, and variadic recursion is not always a great option either.

The entire point of parameter packs is to pass a flexible amount of parameters to a function (in other words, an implicit template), so being able to index them directly would save a lot of trouble in some situations.

More than anything, I think it's just really strange that the pack itself is variadic, but somehow the index must be a constant expression? Doesn't that undermine the nature of variadic expressions?

I guess we can only hope for a constexpr for someday...

[LB--]

What do you expect the result of decltype(pack...[i]) to be when i is not a constant expression?

[WotJProject]

What do you expect the result of decltype(pack...[i]) to be when i is not a constant expression?

Simple: I would expect it to work the same way as decltype(auto), because like auto, parameter packs are known at compile time. As long as the index can be inferred at compile time (which it can for any set of data known at compile time), it should be a non-issue.

What I would really expect is for the compiler to unroll loops and resolve non-constexpr indices, just as they do with many constexpr arrays. My problem isn't directly that the index can't be a constant expression; it's that I can't set the max index and run a for-loop over the pack based on the templated size of the pack. That's why I want a constexpr for.

I am aware of template for, but I can't find a lot of solid documentation on it, so I don't even know if it can resolve this or not.

[LB--]

Ok, so what you actually want is some sort of magic automatic loop unrolling that can convert the loop index from a runtime value to a constant expression value, as long as the compiler can figure out a way to do it? That's quite a lot more complex to solve generally than these simple code snippets make it out to be, and getting anything like that standardized is going to be difficult. We can already do the equivalent ourselves with std::make_index_sequence and std::index_sequence_for and pack expansions on lambdas, the syntax isn't as nice but it's doable now while waiting for some alternative template for/constexpr for syntax. I don't think we'll ever get it with plain for though, at least not this decade.

[WotJProject]

I'm not familiar with those functions, I'll have to look them up. If it can successfully index the pack without any additional copying of the parameters, that would be a good solution.

And magic would be nice, but it's a bit overkill for something that is known at compile time. Again, this is something the compiler already does, sometimes even for regular const-qualified arrays at higher optimization levels, to say nothing of constexpr ones. Even assuming the parameters aren't stored contiguously, this would be like unrolling a loop indexing an array of pointers, it's absolutely trivial and can be done manually in ways that, again, I already demonstrated in my code sample in 4 different ways.

I'm not debating whether or not it's possible, because it is.
All I'm asking is why this couldn't be part of the pack indexing in the first place, instead of making me jump through unnecessary hoops to do it. The entire point of variadic functionality is to have templating auto-fill the appropriate constraints and values. Why would anyone even use pack indexing if they can't index it normally?