The following code, compiled with -Wall -std=c++11 -pedantic is rejected by gcc 4.7.2 and gcc 4.8.0 20130106 (experimental): //--------------------- struct S { int foo(){ return 0; } }; template<class... Args> void evaluate(Args...){} template <class... Args> void bar(Args... args) { evaluate(args.foo()...); // OK auto lmb = [=](){ evaluate(args.foo()...); }; // Error lmb(); } int main() { S s{}; bar(s); } //--------------------- "11|error: parameter packs not expanded with '...':| 11|note: 'args'| In instantiation of 'void bar(Args ...) [with Args = {S}]':| 17|required from here| 11|error: using invalid field 'bar(Args ...)::__lambda0::__args'| " The problem also occurs for class member expressions of the form E1->E2 instead of E1.E2.
I suspect this is just a different manifestation of PR41933.
(In reply to comment #1) > I suspect this is just a different manifestation of PR41933. Thanks Paolo, I partially agree. Indeed the problem is not depending on class member expressions (so the issue title should be fixed), a simplified example can be written as: //-------------------- struct S {}; template<class... Args> void evaluate(Args...){} template <class... Args> void bar(Args... args) { evaluate(args...); // OK auto lmb = [=](){ evaluate(args...); }; // Error lmb(); } int main() { S s{}; bar(s); } //-------------------- with the error: "9|error: parameter packs not expanded with '...':| 9|note: 'args'| 9|error: expansion pattern 'args' contains no argument packs| |In instantiation of 'void bar(Args ...) [with Args = {S}]':| 15|required from here| 9|error: using invalid field 'bar(Args ...)::__lambda0::__args'|" The reason why I hesitate to agree with that being a dup of bug 41933 is due to the fact that the corresponding example there depends on a language extension described in http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#904 that is not part of C++11. I do think though, that my revised example above is indeed conforming C++11 because it does not depend on that grammar extension. Please keep that in mind when considering the category change to DUP, because that would have impact on which versions of gcc to patch. For example, I assume that any CWG defect 904 association would presumably not be applied to gcc 4.7.2.
Thanks Daniel, don't worry I'm not going to close anything for now. But we should really clarify in PR41933 that the issue isn't about C++11 proper.
Daniel, are you sure PR41933 isn't C++11 proper? I gather that the corresponding Core issue (which at the time Jason also referenced) went into CD2, thus isn't just C++11?!?
(In reply to comment #4) You are right, I missed the CD2 tag
*** Bug 57817 has been marked as a duplicate of this bug. ***
Fixed for 4.9.0 by the patch which fixed c++/41933.
Is this bug fixed in 4.8.3? I don't find here Known to work: 4.9.0 Known to fail: 4.7.2, 4.8.0
(In reply to Balakrishnan B from comment #8) > Is this bug fixed in 4.8.3? I don't find here > > Known to work: 4.9.0 > Known to fail: 4.7.2, 4.8.0 Apparently this is was not backported to the 4.8 series, as 4.8.5 still fails with the simplified example in comment #3.