From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-4316.protonmail.ch (mail-4316.protonmail.ch [185.70.43.16]) by sourceware.org (Postfix) with ESMTPS id 83B523858D33 for ; Mon, 27 Nov 2023 01:30:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 83B523858D33 Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=protonmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=protonmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 83B523858D33 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.43.16 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701048627; cv=none; b=JyNc7uYl2vJASHhlTyv28FBs9Un9VGfUygc/Z7YWoFjJDmE9aUBrLKI20RoImBuBdZTLXU8K1CoI1RAlfOm8GClKMCm7HWOAUwwTF9ae0a//rtVwpgckqu/0DXywZuF1YwLH5HWLne8foLIJEnH5XlYgrClmj9gyu86w6l+ctMc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701048627; c=relaxed/simple; bh=SbnEAOMAD5k4KVwENZr1o/7w/PRbL2tZbAfWvNTzt+M=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=Fnixja+e39v/w9BynbDaZG4qITIYLuzkqiitabaCyR5F2TeWDh1XRBWWPVkiTu609Sa77uNPl8B6AE5ya7HBXZaS9BGje9OoatSg2TzjQXOkVwXriXgTmrosiubrT8155SPjijBZ0XTYAsBaDZc3MLh0Ca3PeHP99bldw9JmWbk= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701048624; x=1701307824; bh=t0xOuYdAmqiRnlQN7tespyMET/JKG8GLxqcSuL27t94=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=Om7DhqahRDtw6iIE2uVM5SwZxrR9eqE7j7rhGwjLB+eJr35HxxNEnNllgG0oa/Afq jQUzWjilWLpUU8eVW1Zf/bNIekE+lRxgvkXrQLeb72IZASI4YOJaxHN6fagcifCRIh CzczkAGBDsF/Q+6NbLUmd4WHrWOL19KnMV3ZgdbS9zWSjZx7eoyTblVtzpXWNlUKuQ exbkVgy40j4PRCZ2uSDV4Tf7AYeCiTerxcePNSvgYPlMTwbcBVvs5Iv+OiVTu1oUZI FWUT5QwX+UycJ0ox3jW3U7lR+onghdkaROLOgYSiHycjWUxpghA925xInE7KLqbaVf x95NtxKTKGI+g== Date: Mon, 27 Nov 2023 01:30:20 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v5 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: <7623e2db-ba29-42f2-85df-c2e796d7305b@redhat.com> References: <9OlK_2c3Punfm3w-wEHqyHGyKGG8Gr_K0BUnDOuC9Aazur4mWlAM5WuL1Ea0AMLvFLl6LKFVTs813yY0zA7m0_ji_R9qhE52G7MZXrVPfZE=@protonmail.com> <7Xr5Vil7ptZzPaCtc_ZCdcTPuUVY7dheOnklF-vVDb5_jl8PivYWgTT_f3cKLvg7IMnDruCDDrICRI6WVrUT3f8ZScGKAh4ATIkYSuRqPZc=@protonmail.com> <-SP7aKgN1FZED-RAPr2FBDuCrcwnu9-UhHcRXNEsNZRwIzJXCdhVbtBP921Yn8g71d0WL7XpFRetUlBAStzRpZB8p4yj5moRS0DIE9D6cnY=@protonmail.com> <7623e2db-ba29-42f2-85df-c2e796d7305b@redhat.com> Feedback-ID: 14591686:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-3.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_MSPIKE_H5,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: > > Now with that out of the way, I do still kind of feel icky about it. > > This really is a MASSIVE edge case that will almost never matter. As > > far as I know, instantiating explicitly like so... > >=20 > > auto f =3D [x =3D 42](this auto&&) -> int { return x; }; > > int (*fp)(int&) =3D &decltype(f)::operator(); > >=20 > > ...is the only way to coerce the explicit object parameter of the > > lambda's call operator into deducing as an unrelated type. Cases that > > are not deduced can be caught trivially while parsing the lambda and > > are the only reasonable cases where you might have an unrelated type. > > Perhaps it might become relevant in the future if a proposal like > > https://atomgalaxy.github.io/isocpp-1107/D1107.html ever made it in, > > but we aren't there yet. So as it stands, I'm pretty certain that it's > > just impossible to instantiate a lambda's call operator with an > > unrelated xobj parameter type except for the above case with > > address-of. If you can think of another, please do share, but I've > > spent a fair amount of time on it and came up with nothing. >=20 >=20 > I think you're right. >=20 I was about to send a quick e-mail amending this, before I respond to everything else I want to include this test case I just came up with minute= s ago. template struct S : T { using T::operator(); operator int() const {return {};} }; int main() { auto s0 =3D S{[](this auto&& self) { return self; }}; auto s1 =3D S{[x =3D 0](this auto&& self) { return self; }}; s0.operator()(); s1.operator()(); } So I was wrong, but, the good news is that this does demonstrate that there is a code path where my diagnostic works. template concept NotInt =3D (!__is_same (T, int)); template struct enable_if {}; template<> struct enable_if { using type =3D decltype(nullptr); }; template using enable_if_t =3D typename enable_if::type; template void using_concepts(T) {} template =3D nullptr> void using_enable_if(T) {} void test() { void (*fp_concepts)(int) =3D &using_concepts; void (*fp_enable_if)(int) =3D &using_enable_if; using_concepts(0); using_enable_if(0); } I also have this test case that demonstrates the difference in diagnostic quality. This is unrelated to explicit object member functions though, but it does demonstrate that the diagnostics that I currently produce are in equal quality to the ones already produced in these cases. At this point I feel like I am unlikely to start fixing the bug with captures not being treated as const tonight. Cleaning up the tests is takin= g me longer than I thought. Anyway I'm just rushing this e-mail to clarify this mistake, admittedly I a= m a little excited to have found (which in hindsight should have been obvious= ) a test case that more directly calls a lambda's call operator with an unrelated type. Alex