C++ expected-to-fail compilation goes through by not detecting mutable-specifier on lambda...

C++ expected-to-fail compilation goes through by not detecting mutable-specifier on lambda...

[leon zadorin]

Hi, a quick question on whether GCC/clang are doing it correctly or whether
MSVC is more correct...

Given the following:

template<typename T>
void foo(T const f)
{
    f();
}

struct S {
    void operator()()
    {
    }
};

int main()
{
    foo(S());
}

... the above fails to compile as expected (need to add 'const' qualifier
to operator()() to make it work).

However, if replacing 'struct s' with similar lambda semantics, the effect
of 'mutable' (i.e. making operator()() non-const) are not detected by
GCC/clang to a point where both of the following compile ok:
int main()
{
    foo([](){});
    foo([]() mutable {});
}

... whereas MSVC will compile (as expected)
   foo([](){});
but will barf (which feels also more, it least intuitively, correct) on
   foo([]() mutable {});
(because latter has non-const lambda's operator()()) ...

So I was just wondering whether MSVC is correct or may be its just me and I
need to read more and proper about C++ standard on how lambda's mutable
specifier is treated in various contexts? :) or may be I just need to brush
up on C++ standard altogether :)

Best regards
Leon.

Re: C++ expected-to-fail compilation goes through by not detecting mutable-specifier on lambda...

[leon zadorin]

On Mon, Mar 2, 2020 at 1:57 PM leon zadorin <leonleon77@gmail.com> wrote:
>
> template<typename T>
> void foo(T const f)
> {
>     f();
> }
...
> the effect of 'mutable' (i.e. making operator()() non-const) are not
detected by GCC/clang to a point where both of the following compile ok:
> int main()
> {
>     foo([](){});
>     foo([]() mutable {});
> }
>

... actually never mind, I take it back :)  I think GCC/clang are ok in
that regard, reading https://en.cppreference.com/w/cpp/language/lambda
"mutable: allows body to modify the parameters captured by copy, and to
call their non-const member functions"

makes it more clear for me... as in the above lambdas have no captures
anyways (i.e. no effect), and with any captures (e.g. mutating with
mutable) the expected compilation failure becomes evident, so in effect
GCC/clang are doing this fine :)

sorry for the noise everyone :)

Kind regards
Leon.

Re: C++ expected-to-fail compilation goes through by not detecting mutable-specifier on lambda...

[Jonathan Wakely]

On Mon, 2 Mar 2020 at 03:55, leon zadorin <leonleon77@gmail.com> wrote:
>
> On Mon, Mar 2, 2020 at 1:57 PM leon zadorin <leonleon77@gmail.com> wrote:
> >
> > template<typename T>
> > void foo(T const f)
> > {
> >     f();
> > }
> ...
> > the effect of 'mutable' (i.e. making operator()() non-const) are not
> detected by GCC/clang to a point where both of the following compile ok:
> > int main()
> > {
> >     foo([](){});
> >     foo([]() mutable {});
> > }
> >
>
> ... actually never mind, I take it back :)  I think GCC/clang are ok in
> that regard, reading https://en.cppreference.com/w/cpp/language/lambda
> "mutable: allows body to modify the parameters captured by copy, and to
> call their non-const member functions"
>
> makes it more clear for me... as in the above lambdas have no captures
> anyways (i.e. no effect), and with any captures (e.g. mutating with
> mutable) the expected compilation failure becomes evident, so in effect
> GCC/clang are doing this fine :)

What they're doing seems kinda OK, but I think it's not actually
allowed by the standard. The wording does say that unless the lambda
uses the mutable keyword, the function call operator is
const-qualified.

So I think this is a bug.

Re: C++ expected-to-fail compilation goes through by not detecting mutable-specifier on lambda...

[leon zadorin]

On Tue, Mar 3, 2020 at 9:57 PM Jonathan Wakely <jwakely.gcc@gmail.com>
wrote:
> What they're doing seems kinda OK, but I think it's not actually
> allowed by the standard. The wording does say that unless the lambda
> uses the mutable keyword, the function call operator is
> const-qualified.
>
> So I think this is a bug.

Thanks Jonathan, yep makes sense. I've filed a bug report just in case:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94025