https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025
Bug ID: 94025
Summary: Expected-to-fail compilation goes through by not
detecting mutable-specifier on lambda
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: leonleon77 at gmail dot com
Target Milestone: ---
From a small thread on the gcc-help mailing list
https://gcc.gnu.org/ml/gcc-help/2020-03/msg00003.html
( btw thanks to Jonathan for clearing up various considerations
https://gcc.gnu.org/ml/gcc-help/2020-03/msg00011.html )
there could be a small bug in GCC (albeit not exclusive to GCC :) in that it
doesn't consider the non-const (mutable) nature of lambda's function call
operator when dealing with const objects which are stateless (e.g. lambda
captures nothing).
In the following example:
template<typename T>
void foo(T const f)
{
f();
}
int main()
{
foo([]() mutable {});
}
the compilation would probably be expected to fail if one is to follow the
standard definition for lambda expressions, i.e. "... function call operator
... is declared const if and only if the lambda-expression’s
parameter-declaration-clause is not followed by mutable."
Even though one could ponder the inconsequential nature of the above when being
applied to stateless (captures-nothing) lambdas, for the sake of
standard-compliance and even semantic consistency with explicit, yet
equivalent(?), stateless types such as:
struct S {
void operator()()
{
}
};
int main()
{
foo(S());
}
... which dutifully *fails* to compile unless the function call operator is
const-qualified, perhaps lambda with mutable-specifier should also be
consistent and also fail to compile.
Sorry if I'm splitting hairs here :) (so far from my experiments with various
compilers on godbolt.org MSVC was the only one to detect the above and diagnose
the issue, with gcc and clang allowing it to go through).
