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

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.

Updated.

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.

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.

CWG discussion: please reword all the instances as discussed.