http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52008
--- Comment #8 from Michal Malecki <ethouris at gmail dot com> 2012-04-21 12:06:36 UTC --- Jason, There is no better or worse specialization - the first one is a primary template, not a specialization. The example of tuple_slice<1, int, int, int> will just not match the specialization with first argument 0 because, simply, here the first argument is 1. I have stated that the parameter pack is itself not a type specification, just a higher level construct that will be first resolved to the actual list of arguments and only then checked for anything else. But I'm not exactly sure of that, so maybe the argument pack specification should undergo specialization rules by itself. There are, for me, only two logical methods to solve this problem: 1. The code is accepted, even though it violates the standard a bit; pedantic flags may turn it off. In particular, the specialization is treated as really a specialization because it matches the name and all tries to instantiate the primary template can be redirected to the specialization, as long as it matches the specialized argument. Both the specialization and the primary template are considered only after the argument pack is expanded, in which case both will expand to exactly the same list of arguments - so the "expanded versions" will have the primary-specialization relationship. 2. The code is rejected the following way: the template specialization definition is itself rejected because due to not covered explicitly all explicit parameters (that is, all but parameter pack) this is not considered template specialization. But the template specialization can only be considered invalidly defined specialization, if template parameters that are passed to the template are incorrect according to the template parameter definition in the primary template.
