From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch [185.70.40.131]) by sourceware.org (Postfix) with ESMTPS id 2DD6A3858C29 for ; Sat, 2 Dec 2023 01:31:43 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2DD6A3858C29 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 2DD6A3858C29 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.131 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701480704; cv=none; b=g8XlKFMVB5Zg/eMiSnH2SsA0tGCUPQf6H6FsXQQSIo7CANxS2N6TWuOAMBDy+RGWB5j3II6FM//z8LZf5Pm5zekkuXkyIEtXCzmNCd8WSukwXJwUd9irvhNa2O/0tr38+p0Z2/UXzixL7nJL2x4Gbv4c/iX2VvMlGn67IcbFgg4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701480704; c=relaxed/simple; bh=sT/I0XiGfvzkazrQrVjkRTbDP3LnbBsMMx3x/LKF0YQ=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=GX+DRuYKNMMNzc0ih3okVrRsJO8+tljmCpZDrhRhsvJkamLgpctpgHtE7EdReSM8hR2rIxvtaHvl3KxMoSCE222uBv523pyBAph3FwEdt66DCBHszzCPb2u8F3BhqIqMMDsih/19ocQ4euD42kONTG1kTZrC8rGbgk3roy07dSE= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701480700; x=1701739900; bh=8y9rvmg9sdxQS2DPIxL/WEuUBaueYJPw6e7luHq+XYs=; 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=SsGfV7oKctUf+3HZFrm290LVfgTyJEt7mbPCzdrpp0XS+OjixK4bX0BR3X39qAXRO yuEYh3N1QcEe19TiddX+q13WgpRiJSdyWBrcTz19gAOoMGC2S0EgzXlNEINSR2nwdH 4cshRc2UWnRHllXftYZQLygX3eh3BafbbG2VxgYwRuV/Bhtn5FVf2IRM5keWbXHQDL WFrJ5dXJ6k1vgdMPaUapY1B85xMNPfSeMO/Rd3BuAUaHk1afjrjYeW3XSKimYc0bdT f7zTLHgK3m5IuM1jDrngtpTMn0VkOjQz8ge804dZ46CfYdLzb53YSj8X094OS7iGU5 2GFyTzM2EpWng== Date: Sat, 02 Dec 2023 01:31:26 +0000 To: Jason Merrill From: waffl3x Cc: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH v6 1/1] c++: Initial support for P0847R7 (Deducing This) [PR102609] Message-ID: In-Reply-To: <1b3b0259-5ce4-4193-a36d-60f09e1c7c92@redhat.com> References: <-SP7aKgN1FZED-RAPr2FBDuCrcwnu9-UhHcRXNEsNZRwIzJXCdhVbtBP921Yn8g71d0WL7XpFRetUlBAStzRpZB8p4yj5moRS0DIE9D6cnY=@protonmail.com> <7623e2db-ba29-42f2-85df-c2e796d7305b@redhat.com> <_e1O52EjoN_BFiH31iHE-0eYegNJhoOdDN2O0mduqtMmt7qTGpRWgduxNppnO1si01rORJ470oWcoM-_lk1ICFo9lhe_ylBKQsJ791qMm_k=@protonmail.com> <1b3b0259-5ce4-4193-a36d-60f09e1c7c92@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.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,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: On Friday, December 1st, 2023 at 9:52 AM, Jason Merrill = wrote: >=20 >=20 > On 12/1/23 01:02, waffl3x wrote: >=20 > > I ran into another issue while devising tests for redeclarations of > > xobj member functions as static member functions and vice versa. I am > > pretty sure by the literal wording of the standard, this is well formed= . > >=20 > > template > > concept Constrain =3D true; > >=20 > > struct S { > > void f(this auto, Constrain auto) {}; > > static void f(Constrain auto) {}; > >=20 > > void g(this auto const&, Constrain auto) {}; > > static void g(Constrain auto) {}; > >=20 > > void h(this auto&&, Constrain auto) {}; > > static void h(Constrain auto) {}; > > }; > >=20 > > And also, > >=20 > > struct S{ > > void f(this auto) {}; > > static void f() {}; > >=20 > > void g(this auto const&) {}; > > static void g() {}; > >=20 > > void h(this auto&&) {}; > > static void h() {}; > > }; > >=20 > > I wrote these tests expecting them to be ill-formed, and found what I > > thought was a bug when they were not diagnosed as redecelarations. > > However, given how the code for resolving overloads and determining > > redeclarations looks, I believe this is actually well formed on a > > technicality. I can't find the passages in the standard that specify > > this so I can't be sure. >=20 >=20 > I think the relevant section is > https://eel.is/c++draft/basic.scope.scope >=20 > > Anyway, the template parameter list differs because of the deduced > > object parameter. Now here is the question, you are required to ignore > > the object parameter when determining if these are redeclarations or > > not, but what about the template parameters associated with the object > > parameter? Am I just missing the passage that specifies this or is this > > an actual defect in the standard? >=20 >=20 > I think that since they differ in template parameters, they don't > correspond under https://eel.is/c++draft/basic.scope.scope#4.5 so they > can be overloaded. >=20 > This is specified in terms of the template-head grammar non-terminal, > but elsewhere we say that abbreviated templates are equivalent to > writing out the template parameters explicitly. >=20 > > The annoying thing is, even if this was brought up, I think the only > > solution is to ratify these examples as well formed. >=20 >=20 > Yes. >=20 > Jason I can't get over that I feel like this goes against the spirit of the specification. Just because an object argument is deduced should not suddenly mean we take it into account. Too bad there's no good solution. I especially don't like that that the following case is ambiguous. I understand why, but I don't like it. template concept Constrain =3D true; struct S { int f(this auto, Constrain auto) {}; static f(auto) {}; }; main() { S{}.f(0); } I would like to see this changed honestly. When an ambiguity is encountered, the more constrained function should be taken into account even if they normally can't be considered. Is there some pitfall with this line of thinking that kept it out of the standard? Is it just a case of "too hard to specify" or is there some reason it's impossible to do in all but the simplest of cases? Anyway while I do think this behavior is bad (not wrong according to the standard, but bad imo), I recognize I don't have time to think about it right now so I'll go back to working on the patch for the time being. Alex