[expr.prim.lambda.general] Added missing definition for the term "lambda".

[Bekenn]

The unadorned term "lambda" is used interchangeably with lambda-expression in a few places, but is never actually defined. The term "generic lambda" is defined in terms of "lambda". Adding the missing definition seemed like the simplest approach to resolving the issue.

[JohelEGP]

As for the commit message, see https://github.com/cplusplus/draft/wiki/How-to-submit-an-editorial-issue#regardless.

[Bekenn]

Do you want an amended commit, or should I just change the PR title?

[JohelEGP]

It'd be easier on the editors if the commit message was right from the start.
But they can also fix it when merging the PR.

[Bekenn]

Updated.

[jensmaurer]

Hm...

I'm not too fond of splitting up "generic lambda" into "lambda is generic"; I think we use "generic lambda" (in this order) whenever we us that term.

What's the count on plain "lambda" that we would need to turn into "lambda-expression"?

I understand that using "lambda-expression" on one hand and "generic lambda" on the other is a bit non-symmetric in phrasing, but that feels like the lesser evil right now.

[Bekenn]

Here are the cases I could find:

• [basic.def.odr]/10 uses the term "non-lambda function"
• [dcl.spec.auto.general]/2: "or the lambda is a generic lambda" (this is in a note, so maybe not important)
• [dcl.attr.depend]/1: "The attribute may be applied to a parameter of a function or lambda"
• [dcl.attr.depend]/1: "lambda call operator" (also [dcl.attr.nodiscard] and [dcl.attr.noreturn])
• [expr.prim.lambda.general]/6: "A lambda is a generic lambda if the lambda-expression has any generic parameter type placeholders, or if the lambda has a template-parameter-list."
• [expr.prim.lambda.closure]/4: "(for a non-generic lambda)"
• [expr.prim.lambda.closure]/5: "Given a lambda with a lambda-capture, the type of the explicit object parameter, if any, of the lambda’s function call operator"
• [expr.const]/17: "the call operator of a lambda"
• [defns.prog.def.type]: "non-implementation-provided lambda expression"
• [futures.async]/8: "the lambda might not be invoked" (this appears in a note)

Some of these can readily be replaced with lambda-expression, but others feel a little bit awkward (e.g. "non-generic lambda"). Some of these uses appear to refer to the closure type rather than the lambda-expression itself.

[tkoeppe]

CWG discussion: please reword all the instances as discussed.