[Bug c++/58527] New: Failures when a function parameter pack is not final

[Bug c++/58527] New: Failures when a function parameter pack is not final

[nmm1 at cam dot ac.uk]

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

            Bug ID: 58527
           Summary: Failures when a function parameter pack is not final
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nmm1 at cam dot ac.uk

This may be already reported, but I can't see how to search for it.  Sorry.

#include <iostream>
using namespace std;

template<typename ... Pack>
void weeble(Pack ... rest, double x) {
    int y[] = {rest...};
    for (int i = 0; i < sizeof(y)/sizeof(*y); ++i) cout << y[i] << " ";
    cout << x << endl;
}

int main () {
    weeble(123,456,789,3.1416);
}

fails with:

junk.cpp: In function 'int main()':
junk.cpp:12:30: error: no matching function for call to 'weeble(int, int, int,
double)'
     weeble(123,456,789,3.1416);
                              ^
junk.cpp:12:30: note: candidate is:
junk.cpp:5:6: note: template<class ... Pack> void weeble(Pack ..., double)
 void weeble(Pack ... rest, double x) {
      ^
junk.cpp:5:6: note:   template argument deduction/substitution failed:
junk.cpp:12:30: note:   candidate expects 1 argument, 4 provided
     weeble(123,456,789,3.1416);
                              ^
Now, it may well be illegal, though I can't spot anything in C++11.
It would certainly be illegal if it were the <cstdarg> 'equivalent'.
But it is parsable, in theory, even more so in my original form.

However, that's not my sole point.  If it is illegal, why isn't it
being rejected when the function template is being parsed, rather than
left to type resolution to fail weirdly?  Intel is even more amusing,
incidentally :-)

Other information:

COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/nmm/GCC/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/home/nmm/GCC --disable-bootstrap
--enable-languages=c,c++,fortran --enable-werror=yes --disable-decimal-float
Thread model: posix
gcc version 4.8.1 (GCC)
COLLECT_GCC_OPTIONS='-std=c++11' '-Wall' '-Wextra' '-Wno-unused-parameter'
'-fno-elide-constructors' '-g' '-O3' '-I' '/home/nmm/Courses/C++/Includes' '-I'
'.' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'

Linux wheeler 2.6.37.6-24-desktop #1 SMP PREEMPT 2012-10-18 22:36:08 +0200
x86_64 x86_64 x86_64 GNU/Linux

[Bug c++/58527] Failures when a function parameter pack is not final

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> ---
The parameter pack can only be deduced if it is in last position (that's an
arbitrary restriction, but it is in C++11). However, you can still do:
  weeble<int,int,short>(123,456,789,3.1416);

[Bug c++/58527] Failures when a function parameter pack is not final

[nmm1 at cam dot ac.uk]

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

--- Comment #2 from Nick Maclaren <nmm1 at cam dot ac.uk> ---
Thanks.  I can't use your fix, because I am trying to write a generic
multi-dimensional array class for possible inclusion in the standard,
and demanding such usages from end users is Not On.  There are other
possibilities, of course.

I would be interested in a reference to the wording in the standard,
if you know it offhand.  I failed to find it.

But that doesn't address the other point.  Even if C++ allows a parameter
pack in a position where it cannot be deduced (and that would not be at
all surprising), good practice would be to give at least a warning.  And
I did specify -Wall -Wextra :-)

[Bug c++/58527] Failures when a function parameter pack is not final

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse <glisse at gcc dot gnu.org> ---
(In reply to Nick Maclaren from comment #2)
> I would be interested in a reference to the wording in the standard,
> if you know it offhand.  I failed to find it.

[temp.deduct.call]

For a function parameter pack that occurs at the end of the
parameter-declaration-list, the type A of each remaining argument of the call
is compared with the type P of the declarator-id of the function parameter
pack. Each comparison deduces template arguments for subsequent positions in
the
template parameter packs expanded by the function parameter pack. When a
function parameter pack appears in a non-deduced context (14.8.2.5), the type
of that parameter pack is never deduced. [ Example:

template<class ... Types> void f(Types& ...);
template<class T1, class ... Types> void g(T1, Types ...);
template<class T1, class ... Types> void g1(Types ..., T1);
void h(int x, float& y) {
const int z = x;
f(x, y, z); // Types is deduced to int, float, const int
g(x, y, z); // T1 is deduced to int; Types is deduced to float, int
g1(x, y, z); // error: Types is not deduced
g1<int, int, int>(x, y, z); // OK, no deduction occurs
}

> But that doesn't address the other point.  Even if C++ allows a parameter
> pack in a position where it cannot be deduced (and that would not be at
> all surprising), good practice would be to give at least a warning.

There are perfectly legitimate reasons to write such code, and no way to tell
the compiler that we know what we are doing, so I wouldn't include it in Wall.
But sure, feel free to add a warning for this, it may indeed help.

[Bug c++/58527] Failures when a function parameter pack is not final

[paolo.carlini at oracle dot com]

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|---                         |INVALID

--- Comment #4 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Closing.