Date: Sun, 30 Nov 2025 11:32:41 +0100
hello,
waiting for any answer on this topic.
Let me ignore previous messages on it.
I am suggesting to review
https://eel.is/c++draft/expr.prim.lambda.capture#14.1
which reads
"... if m1 is not mutable, the non-static data member is considered to be
const-qualified."
IMO, this wording rules out the case of explicit object parameter deduced
as non-const-qualified closure type (or its derivation, as well as
references
to such types... i.e., the same listed for the case of non-empty captures in
https://eel.is/c++draft/expr.prim.lambda#closure-6),
even because the term 'mutable' in the reported wording "is not mutable" is
formatted to indicate the language keyword, isn't it ?
Also, no general definition of "mutable" lambda is provided to include the
case of explicit object parameter.
Likely, a possible solution without introducing a generalized concept of
mutable
lambda, might be to lengthen the reported wording with something like:
", unless the explicit object parameter, if any, is deduced as non
const-qualified type (or reference to)."
where I supposed that it's not really needed to explicit the list of
allowed types,
since the discussed wording is in a context with non-empty capture,
necessarily
leading to restrict the deduced types to the list of the aforementioned
clause #6.
Kind regards.
Mauro.
waiting for any answer on this topic.
Let me ignore previous messages on it.
I am suggesting to review
https://eel.is/c++draft/expr.prim.lambda.capture#14.1
which reads
"... if m1 is not mutable, the non-static data member is considered to be
const-qualified."
IMO, this wording rules out the case of explicit object parameter deduced
as non-const-qualified closure type (or its derivation, as well as
references
to such types... i.e., the same listed for the case of non-empty captures in
https://eel.is/c++draft/expr.prim.lambda#closure-6),
even because the term 'mutable' in the reported wording "is not mutable" is
formatted to indicate the language keyword, isn't it ?
Also, no general definition of "mutable" lambda is provided to include the
case of explicit object parameter.
Likely, a possible solution without introducing a generalized concept of
mutable
lambda, might be to lengthen the reported wording with something like:
", unless the explicit object parameter, if any, is deduced as non
const-qualified type (or reference to)."
where I supposed that it's not really needed to explicit the list of
allowed types,
since the discussed wording is in a context with non-empty capture,
necessarily
leading to restrict the deduced types to the list of the aforementioned
clause #6.
Kind regards.
Mauro.
Received on 2025-11-30 10:32:56
