[Bug c++/51155] Incorrect sizeof and sizeof... behavior in template partial specialization

["daniel.kruegler at googlemail dot com" <gcc-bugzilla@gcc.gnu.org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51155

Daniel Krügler <daniel.kruegler at googlemail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel.kruegler at
                   |                            |googlemail dot com

--- Comment #1 from Daniel Krügler <daniel.kruegler at googlemail dot com> 2011-11-16 08:36:52 UTC ---
(In reply to comment #0)
> 14.5.5.8 of n324 states:
> 
> "A partially specialized non-type argument expression shall not involve a
> template parameter of the
> partial specialization except when the argument expression is a simple
> identifier."
> 
> From what I understand, this seems to be broken when using sizeof:
[..]
> template <int a>
> struct foo<sizeof(a), a> { }; // not correct and compiles

The core language is a bit fuzzy here, but this example should be no problem at
all, because sizeof(a) does not actually depend on the value of a, it just
corresponds to the equivalent of sizeof(int), which is fine. I don't think that
gcc should change the compiler behaviour here unless the core language is
better. IMO the corresponding CWG issue is this one:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1315

I observe that Comeau online accepts this as well.

> Additional bugs when using sizeof.. with a variadic template
> 
> template <int n, int... xs>
> struct foo { };
> 
> // partial specialization:
> template <int... xs>
> struct foo<sizeof...(xs), xs...> { }; // not correct and doesn't compile
>                                       // although it should if sizeof is
> allowed
> 
> template <int... xs>
> struct foo<sizeof(xs), xs...> { };    // not correct and compiles
>                                       // sizeof(xs) evaluates to sizeof(int)
>                                       // which is incorrect

I agree that this should be ill-formed, it looks as if gcc incorrectly performs
an implicit unpacking of the parameter pack xs here. It does so correctly
within the body of a class template.