Simultaneous parameter pack expansion error for unused template type definition

Question

The problem that I have encountered is the following warning from clang (c++14):

Pack expansion contains parameter pack 'v_seconds' that has a different length (3 vs. 1) from outer parameter packs

The issue is encountered in the following example code:

template<typename... v_firsts>
struct types_list {
    template<typename... v_seconds>
    using pairs_list = types_list<std::pair<v_firsts, v_seconds>...>;
};

using my_types_list = types_list<short, int, long>;

using my_pairs_list = my_types_list::pairs_list<short, int, long>; // GOOD

template<typename... v_pack>
using any_pairs_list = my_types_list::pairs_list<v_pack...>; // BAD

How I interpret the error is that somehow a specialization of any_pairs_list in which v_seconds has a length of 1 is encountered, and then naturally an error is encountered.

However the code above is the entire example code - I never use a specialization of any_pairs_list.

So, I have to conclude that a specialization is nevertheless created...

Now, the usual TMP forking question:

if (This an intentional behavior of the variadic syntax) {
    Can someone reference some documentation so that I can learn more?
} else if (This a known clang decision or problem) {
    Can someone reference some discussion?
} else {
    Can someone please name the issue / mistake?
}

P.S. I have tested using apple's installation of Clang (v8.1.0) and also with Visual Studio 2017 Clang extension. Unfortunately I don't have a linux environment to test in...

Answer 1

My best guess is that Clang uses some type of heuristic to check for inherently uninstantiable templates. Perhaps it (spuriously) decides that there is one argument to the alias in any_pairs_list because it doesn't deal with pack expansions properly, and then substitutes some unique synthesized type to test whether that could work in principle. After all, you do get the exact same error message if you don't use a pack but just one bog-standard template parameter.

Reported as #32905.