可变参数模板中更好的包扩展语法？

Question

It might be not very efficient to talk about the language syntax that has already been set in stone.

I would, however, like to see why the C++11 variadic template's argument expansion couldn't be more explicit to read when it comes to some nested usage.

For example, I think C++ developers could've generally written code more clearly as follows. (If that's allowed)

template<typename ...> struct Tuple 
{

};

template<typename T1, typename T2> struct Pair 
{

};

template<class ...Args1> struct zip 
{
    template<class ...Args2> struct with 
    {   
        typedef Tuple<Pair<Args1, Args2>...> type;

        // More code but but maybe better readability?
        // because Args1, and Args2 are the ones that get 
        // actually expanded, not Pair<T1, T2>.
        // typedef Tuple<Pair<Args1..., Args2...>> type; // ## Invalid! ##
    };
};


typedef zip<short, int>::with<unsigned short, unsigned>::type T1;

By doing so we don't really have to get confused which template types are exactly being expanded or should be the ones that will have to be expanded when making multiple-nested variadic template , because then it becomes more important for your code to look clearer than being shortened.

Plus I'd love to see the code in the same manner where I call a function as follows:

Foo(args...); // Okay.

We don't do like this:

Foo(args)...; // Error.

EDIT

I believe this one should've been at least allowed to work nicely.

Tuple<Pair<Args1..., Args2...>> // Invalid code.

But it does not.

Why not? Is there any potential risk to convince the committee enough to prevent it from compiling?

Thank you so much in advance.

Answer 1

In every one of your cases, your "preferred" notation does a different expansion than the one you want. They aren't invalid.

If Args0 = { a,b,c } and Args1 = { int,double,char } then:

std::tuple< foo< Args0..., Args1... > >

is

std::tuple< foo< a,b,c,int,double,char > >

while

std::tuple< foo< Args0, Args1>... >

is

std::tuple< foo< a, int >, foo< b, double >, foo< c, char > >

The thing is, these are both useful operations.

The key is ... operates on potentially-expanded sub-"expressions", not on packs directly.

Unless your proposed notation can generate both of these results, it is a weaker notation.

The same thing holds true with Foo(Args)... and Foo(Args...) . They aren't alternate ways to say something -- they are ways of saying two different things in current C++. Your plan results in in the 2nd meaning the 1st, which means there is no longer a way to express what the 2nd means in your version of C++.

There are two parts to each expansion. The first is what packs are being expanded, the second is what "expression" is being expanded. The packs being expanded, in current C++, are all unexpanded packs within the expression: they are not otherwise marked.

In your version, you mark the packs to expand, and never mark the expression to be expanded. If the language read your mind, it could figure out where that expression was, but programming languages that read your mind are usually a bad idea.

A side effect of "mark the expression, not the pack" is that you can do some seriously powerful stuff, like have entire lambdas that contain unexpanded packs inside expressions inside the body, and then generate a pack of lambdas. Expressing that in your system would be challenging.