GCC doesn't like this: void slurp(...) { } template<int ...N> void print() { slurp([]() -> int { (void) N; // or something fancy... return 0; }() ...); } void f() { print<1, 2>(); } Error: error: parameter packs not expanded with '...': I think the draft (n3225) says this should expand "N" and result in: slurp( []() -> int { (void) 1; // or something fancy... return 0; }(), []() -> int { (void) 2; // or something fancy... return 0; }());
I asked the committee at that time, and they reinforced that this is intended to work as specified in the C++11 spec.
The problem still exists in gcc 4.8.0 20120610 (experimental) compiled with -Wall -pedantic -std=c++11. Here a variation of Johannes example based on a similar Clang bug report from Doug Gregor: //---- template<class T> void print(const T&) {} template<class... T> void accept_all(T&&...){} template<class... T> void print_all(const T&... t) { accept_all([&]()->int { print(t); return 0; }...); // Line 10 } int main() { print_all(1, true, 'a'); } //---- "10|error: parameter packs not expanded with '...':| 10|note: 't'| |In function 'void print_all(const T& ...)':| 10|error: expansion pattern '#'lambda_expr' not supported by dump_expr#<expression error>' contains no argument packs"
Is this a duplicate of Bug 41933 ?
(In reply to comment #3) > Is this a duplicate of Bug 41933 ? This looks like a different one. I am not trying to capture a list of variables that result of expansion of a function parameter pack, but I'm just trying to use an element (a type or in this case, a non-type template parameter) of a pack expansion within a lambda. For a real life example, consider http://stackoverflow.com/a/13444602/34509
Created attachment 31544 [details] Testcase for bug 47226 I encountered this bug last week with gcc 4.8.1. I attached a minimal test case for this bug and was wondering if there is any progress on implementing this feature. As I understand parameter packs in combination with lambdas weren't implemented until bug 41933 was fixed in September this year. So I'm hoping somebody is working on this particular bug as well.
This still exists in GCC 6.0.0 20150902 (also I've heard MSVC manages to work with this. Come on, guys, don't be worse than MSVC *when it comes to templates*. Clang of course also understands what's going on).
I'm suffering from this bug too. It currently break my CI since I can't use clang too due to ABI changes. This is 3 years-old: I hope someone will take a look on it.
I'm hit too.
Got hit as well, in g++ 7.0 trunk: http://stackoverflow.com/questions/40752568
I have the following in my code now: // this could be much simpler: // // return {V([&](auto i) { return x[i + Indexes * V::size()]; })...}; // // Sadly GCC has a bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47226. The // following works around it by placing the pack outside of the code block of the // lambda: return {[](size_t j, const datapar<T, A> &y) { return V([&](auto i) { return y[i + j * V::size()]; }); }(Indexes, x)...};
The project I work on has this: auto const f = std::bind(&Rpc::operator (), &rpc, std::ref(args)...); instead of a simple lambda.
Author: paolo Date: Wed Sep 13 09:47:11 2017 New Revision: 252064 URL: https://gcc.gnu.org/viewcvs?rev=252064&root=gcc&view=rev Log: 2017-09-13 Paolo Carlini <paolo.carlini@oracle.com> PR c++/47226 * g++.dg/cpp0x/lambda/lambda-variadic4.C: New. * g++.dg/cpp0x/lambda/lambda-variadic5.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-variadic5.C Modified: trunk/gcc/testsuite/ChangeLog
Fixed by Jason's https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01678.html. I added a couple of testcases and I'm closing the bug.
*** Bug 64488 has been marked as a duplicate of this bug. ***
*** Bug 83793 has been marked as a duplicate of this bug. ***
Was the patch merged in trunk? The following still fails to compile on 20180407 template <int... Is> int foo() { ([i = Is]{}(), ...); return 0; }
(In reply to Vittorio Romeo from comment #17) > Was the patch merged in trunk? It was committed to trunk: r251433 > The following still fails to compile on 20180407 Could you create a new bug for that please?
(In reply to Jonathan Wakely from comment #18) > (In reply to Vittorio Romeo from comment #17) > > Was the patch merged in trunk? > > It was committed to trunk: r251433 > > > The following still fails to compile on 20180407 > > Could you create a new bug for that please? Created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85305