From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 08292385DC06; Tue, 14 Apr 2020 20:16:56 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 08292385DC06 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1586895417; bh=0Ogsxb7Wsi780wuOKP8Y5GNcrQ78Hf3f1f7Nm0P3Y5c=; h=From:To:Subject:Date:In-Reply-To:References:From; b=tp3bZiG3AD8OsVX0HAdHDNzdTxjX/USbYxEB8Q43wdaNxqAZuE1UkEmbpnsQzDTwY R3n+xjRKFSnjqF18nwfTE8nhMvQcNi61adbuVoCFXBCdJyONqR2qErAiU/gD2e5+sI p55f6e3yayXqYG3jdfblpgIEeyPfJy2jV9Sj8xGs= From: "daniel.kruegler at googlemail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug c++/94025] Expected-to-fail compilation goes through by not detecting mutable-specifier on lambda Date: Tue, 14 Apr 2020 20:16:56 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: c++ X-Bugzilla-Version: 10.0 X-Bugzilla-Keywords: accepts-invalid X-Bugzilla-Severity: normal X-Bugzilla-Who: daniel.kruegler at googlemail dot com X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: cc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Apr 2020 20:16:57 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D94025 Daniel Kr=C3=BCgler changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |daniel.kruegler@googlemail. | |com --- Comment #1 from Daniel Kr=C3=BCgler --- In my opinion, this issue does not demonstrate a bug, but is based on an incomplete analysis of what is going on here.=20 1) It is correct, that the lambda function call operator is non-const in th= is case. The result is that the function call operator of the lambda expression will *not* be called in the shown example. 2) We have here a lambda expression without any capture. This means that the standard requires the existence of an *additional* conversion function to a pointer to function ([expr.prim.lambda.closure] p7 quoted from N4849). And [expr.prim.lambda.closure] p11 says: "The conversion function [..] is public, constexpr, non-virtual, non-explic= it, const, and has a non-throwing exception specification (14.5)." So effectively a second function call resolution is in affect here, selecti= ng the conversion function (which is a const member function as specified abov= e) to function pointer as the only viable candidate (If both were viable, the conversion function would be less preferred) via the surrogate call function ([over.call.object]). That explains IMO why the code is well-formed. If you would try to mimic that with a user-defined class type, it would look similar to the following one: struct Lambda { using f_t =3D void(); f_t operator(); // "mutable" using fptr_t =3D f_t*; operator fptr_t() const; }; Note that I use here the very rarely used syntax to declare (but not define= ) a member function using a typedef for a function type to show the involved function types more precisely. The example would become invalid once you introduce a capture, because in t= his case there would be no conversion function anymore. I'm surprised that the Visual Studio compiler (I tested 2019) rejects the original example, this looks like a bug to me, especially since that compil= er also handles the call resolution for the above defined Lambda type correctl= y. I plan to report an issue for that compiler.=