[Bug c++/94025] New: Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda

[leonleon77 at gmail dot com]

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).