c++ - Unpacking parameter packs in template aliases -

i run problem unpacking variadic templates template alias.

the following code works clang 3.4 , gcc 4.8 fails gcc 4.9:

template <typename t, typename...> using front_type = t;  template <typename... ts> struct foo {   using front = front_type<ts...>; }; 

gcc 4.9 complains:

test.cc:7:37: error: pack expansion argument non-pack parameter 't' of alias template 'template<class t, class ...> using front_type = t'        using front = front_type<ts...>;                                      ^ test.cc:1:15: note: declared here      template <typename t, typename...>                ^ 

there exists filed gcc bug (#59498), supposed fail? here context c++ core language issue #1430, "pack expansion fixed alias template parameter list":

originally, pack expansion not expand fixed-length template parameter list, changed in n2555. works fine templates, causes issues alias templates.

in cases, alias template transparent; when it's used in template can substitute in dependent template arguments. doesn't work if template-id uses pack expansion non-variadic parameters. example:

  template<class t, class u, class v>   struct s {};    template<class t, class v>   using = s<t, int, v>;    template<class... ts>   void foo(a<ts...>); 

there no way express a<ts...> in terms of s, need hold onto a until have ts substitute in, , therefore needs handled in mangling.

currently, edg , clang reject testcase, complaining few template arguments a. g++ did well, thought bug. however, on abi list john spicer argued should rejected.

it reported in gcc4.9 bugzilla:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59498

minimal code reproduce

template <typename t, typename ...> using alias = t;  template <typename ...t> using variadic_alias = alias<t...>;  using fail = variadic_alias<int>;  int main() { } 

---

from explanation gcc folks - it not obvious real bug. still discussion held in gcc bugzilla , in dr 1430 (http://open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1430) - summary in in question above.