[PATCH] D28510: Reinstate CWG1607 restrictions on lambdas appearing inside certain constant-expressions

Richard Smith via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Wed Feb 15 17:59:58 PST 2017


rsmith added a comment.

In https://reviews.llvm.org/D28510#654821, @faisalv wrote:

> In https://reviews.llvm.org/D28510#653794, @rsmith wrote:
>
> > I don't think it's possible to check this in the way you're doing so here. In general, there's no way to know whether a constant expression will be part of a `typedef` declaration or function declaration until you've finished parsing it (when you're parsing the decl-specifiers in a declaration you don't know whether you're declaring a function or a variable, and the `typedef` keyword might appear later).
>
>
>     
>   
>
> I see.  The issue is that the current approach would forbid valid variable declarations such as:
>
> void (*f)(int [([]{return 5;}())]) = 0;
>
> ... where lambdas can appear within the array declarators (I believe that's the only syntactic neighborhood that can cause this problem, right?).


I think so, at least until Louis removes the restriction on lambdas in unevaluated operands. Then we have a whole host of new problems:

  decltype([]{}()) typedef x; // error, lambda in a typedef
  template<typename T> decltype([]{}()) f(); // error, lambda in a function declaration
  template<typename T> decltype([]{}()) x; // ok

If we want a forward-looking change which prepares us for that, we should be thinking about how to deal with deferring the check until we get to the end of the declaration and find out whether we declared a function or a typedef.

> Well lambda's can't appear in unevaluated operands yet, so your example would be ill-formed?  If so, we don't have to worry about them showing up in decl-specifiers?
>  The only Declarator where they could be well formed is within an array declarator of a variable or a parameter of a function pointer variable (but no where else, i.e typedefs and function declarations), right?

Right. But we should at least keep in mind the upcoming removal of the unevaluated operands restriction. Ideally, we would get some implementation experience with that now, so we can make sure that we standardize a reasonable set of rules.


https://reviews.llvm.org/D28510





More information about the cfe-commits mailing list