From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by sourceware.org (Postfix) with ESMTPS id F1D413858D38 for ; Fri, 1 Dec 2023 06:02:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org F1D413858D38 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 F1D413858D38 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=185.70.40.133 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701410549; cv=none; b=rll4e0pzmbAW/iblmi8lqdhTPVNYQBmm/PoIdOoNtu3IASLMOD3dixYkG6le+fr13R+s3fe3iEbHN+Mzu0FsDkm0ajW0zysKxxM4FRV++jq9ZB6gxb5raiGrMc7qXOPBski+4yLjuksQMIziH4zdET4BXEPI9iOBC2znEs7DvJg= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701410549; c=relaxed/simple; bh=2ylwvvixo1C+qMgMn51kBOX4GcsJLnVdj5oMcycZG3Q=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=th3U++5FRXlAj4LC9UeVKREoczUfTbqx9R0X0bR/DKs5XqT0v7IiGl7Xf9dy2Sa3yH/9EBFe0c1hvESnHAQWE+f9JClWDYVWpU0DZ5fWjk64APua2uhwTiMUlal62B6+W3RbISPFfxYtHIAD1mppVXv1t4tcDHqboAowDC0lZIg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701410546; x=1701669746; bh=D4PR/nfhTrH5VZ6fMz5iLcKJLYwbjAWQsgq1Pyn9Djc=; 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=ezuk/0F6IdS4cpLMTsQzrvk/QsinZBv2uL1eVXXAUf/Pt91yurGWGZUzi0l7Nn5Vl 2mob62zl6BV3Kwx4z83rAuWActDInFatcEktExJOsqM+2dK3yUD55WuXaT0HB5MgiU gC22SqyjiTzc247zgwmxRIKJG8ad/4CZVoKk5T1zh55Axt4mNkcFSlfXnR2jbMKYW3 dRRJEtowlfJabl6hEQt3DV+6xtU/8VSCk/h2nuafwfsbnSI6c5+o42rO9Tq78A0lIN iNS38ue76wTBTK0lOqbyZxWkx6a/A2oFOC2aTlT48rubK95nRKlhPjdwHAfYQHvNt4 loL2NZ0GmDsow== Date: Fri, 01 Dec 2023 06:02:14 +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: <_e1O52EjoN_BFiH31iHE-0eYegNJhoOdDN2O0mduqtMmt7qTGpRWgduxNppnO1si01rORJ470oWcoM-_lk1ICFo9lhe_ylBKQsJ791qMm_k=@protonmail.com> In-Reply-To: References: <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=-2.9 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: 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. template concept Constrain =3D true; struct S { void f(this auto, Constrain auto) {}; static void f(Constrain auto) {}; void g(this auto const&, Constrain auto) {}; static void g(Constrain auto) {}; void h(this auto&&, Constrain auto) {}; static void h(Constrain auto) {}; }; And also, struct S{ void f(this auto) {}; static void f() {}; void g(this auto const&) {}; static void g() {}; void h(this auto&&) {}; static void h() {}; }; 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. 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? The annoying thing is, even if this was brought up, I think the only solution is to ratify these examples as well formed. struct S { template void f(this T, T) {} template static void f(T) {} }; Like what about this? If we ignore the template parameters associated with the explicit object parameter, then the template parameter lists don't match. struct S { template typename Templ, typename T> void f(this Templ, T) {} template void f(T) {} }; However, after writing them out and thinking about it a little, maybe it really is just that simple. If after eliminating the template parameters the explicit object parameter depends on the template parameter lists are the same, then it's a redeclaration. Maybe this works? Am I overthinking this? Is there actually something specifying this properly already? Hopefully that's the case but at the very least I managed to write out this e-mail fairly quick for once so I didn't waste too much time on this even if it does turn out to be nothing. The majority of my time here was spent on the test case, which needed to be written anyway. Alex