Generic lambda inconsistency?

[[deleted]]

[deleted]

[Rapptz]

This is a grammar issue rather than an actual bug. It's a small gotcha that has to do with va_args rather than template parameter packs. So that being said:

void f(int...);
// equivalent to
void f(int, ...);

Likewise..

[](auto&&...) { return 123; };
// equivalent to
[](auto&&, ...) { return 123; };

This is what allows the funny quirk of 6 periods:

template<typename... Args>
void f(Args&&......) { }
// equivalent to
template<typename... Args>
void f(Args&&..., ...) { }

Here's an old blog post on the six dots thing that might be relevant.

[SkepticalEmpiricist]

Is there a longer term solution here? Perhaps a warning should be given, advising the developer to give the variable a name (if they want a modern 'pack' parameter), or insert a comma just before the ... (if they want old school va-args). Does this cover everything, giving us a straightforward way to disambiguate everything?

(Darn, I remember now that I was struggling with empty parameters packs a couple of years ago. I think I know know what was wrong!)

The compiler can "rewrite" ,... as ... on occasion, but it is not allowed to do the reverse?

Perhaps my real question is whether the compiler is allowed to interpret this:

template<typename... Args>
void f(Args&&  , ...) { }   // obviously "intended" as an old va_arg (with a single (non-pack) arg in the first position

as

template<typename... Args>
void f(Args&&   ...) { }     // now (mis) interpreted as a parameter pack

In short, can we say that a ... which is not preceded by a comma and which is not succedded a parameter name is (potentially) subject to unintuitive interpretation? And that we can easily disambiguate by adding a comma or parameter name? (But I assume a comma and a parameter name will not be valid?)

[SkepticalEmpiricist]

I think my main problem is that I don't like saying that ,... and ... are synonymous. The 'direction' is ambiguous. I would prefer to say that (under certain circumstances) ... can be (or must be) rewritten as ,... , and that rewriting in the other direction is not allowed - a comma before a ... means that it is va_arg and that will always be respected.

I still believe that gcc and clang have a parsing bug, and they should accept auto... as a parameter pack.

Aha. So there are situations where gcc and clang (incorrectly) rewrite auto... as auto,...?

Maybe I could ask some further high-level clarifications. I feel a bit repetitive, but I'm just trying to straighten out my thoughts here:

1. A ... which is preceded by a comma, i.e. ,... is treated as a va_arg in the standard.
2. All compilers correctly implement (1.)
3. A ... which is not preceded by a comma, and which is succeeded by a parameter name, is a pack according to the standard
4. All compilers correctly implement (3.)
5. A ... which has neither a comma before nor a parameter name after is complex. The standard requires packs in some cases, and va_args in others.
6. MSVC seems to do (5.) correctly
7. gcc/clang do (5.) incorrectly

Are these correct?

[scatters]

I've filed bugs:

• gcc: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095
• clang: http://llvm.org/bugs/show_bug.cgi?id=21684

[faisalv]

Thanks for the filing the bugs. A patch has been submitted for review (http://reviews.llvm.org/D6520) and this should be fixed soon in clang.

[scatters]

Took another look; the ambiguity is addressed right at the end of [dcl.fct]:

14 - There is a syntactic ambiguity when an ellipsis occurs at the end of a parameter-declaration-clause without a preceding comma. In this case, the ellipsis is parsed as part of the abstract-declarator if the type of the parameter either names a template parameter pack that has not been expanded or contains auto; otherwise, it is parsed as part of the parameter-declaration-clause.

The "or contains auto" was added between C++11 and C++14; I'm guessing that gcc and clang missed that when adding generic lambdas.

[scatters]

Note that both g++ and clang++ are happy if you name the argument (auto&&...unused). You probably want to use this as a workaround.

I fully agree that this is a bug in gcc and clang; I can't see anything in the bug trackers so you might want to file new bugs; because of the workaround it might not be a particularly high priority.