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 A56EE385840C for ; Wed, 6 Dec 2023 06:03:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A56EE385840C 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 A56EE385840C 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=1701842595; cv=none; b=R7wCCzTkoIlEa+jjRqsCHlVXljzf0fG93GXjxgk6dzJhEFrb6leS1qkWhApGcWa5gMuHW59t6uY0rsi7zPRXVArz4DiWzZtZEscM8fQmgI7gjxkfuGqWAwBUpN2C8vhz4nn/avIVKHfqPai3BA6XDScji4cYTwnq+H6kgLnDrlw= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1701842595; c=relaxed/simple; bh=cUMdJ0Z+cSDFc/xNC5AqaEYiFhh1OPEEgWqOOQ43TJY=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=LBMS0//kEUDMwRFKtYJIyGq2JMV69I8REbTS6P1KnJICUrZgZO3DdZpFWAkebTiTg+41C5GP5bJNAsNzPF2Tf24AD14SCyHaAcB0tdutB3UKKJB3HKFDL9Egh1Dcrnq77XeHOi1VxBXrh1pwqdLI8VXa+eplA1pGWb/KAXuECHg= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1701842592; x=1702101792; bh=cUMdJ0Z+cSDFc/xNC5AqaEYiFhh1OPEEgWqOOQ43TJY=; 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=p9EGzPU0zwQ2bBH2q/kK4gkOarKgp21YxtWjbEhTtXmCL8Ac0Cp9LMVmlxHvXRm2t xahLCiB1FHWNUvQlFI3cvgfbB4agz4DeiN+Ge71tOLBStXGL36jAgwXSDlGkjZy1/C dp9N3caNCwNeQbAZp7cVw2th1TknyKCDdqih3LrCgzq5sCMDtsnFtqCF2IAwHbfXzf lZ+hO1KDaBoXu/vWUkKXXmNTLxpnUGRDy/zDq9UPkTKVanmQC0LosNzmLLVXY6k+lW jj6EJmfkDnZ8KuSP/sr2NwCZwwOTI+iPVB3HN4Fq/gnQ4bI68tRvfIdRnq78WbSffI JKnhFCl3f0htw== Date: Wed, 06 Dec 2023 06:02:59 +0000 To: Jason Merrill From: waffl3x Cc: gcc-patches@gcc.gnu.org, libstdc++@gcc.gnu.org Subject: Re: [PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499] Message-ID: In-Reply-To: References: <20231206022101.1695009-1-jason@redhat.com> <9XqdQJu8-YLFmxAwH0suhkv87lVeDs7MzukzP_Oftkt1ujN9TCFBccjWrYxfmvvzrIAS4Fcc3b0er8H5KP6K1BwSPjcstmp4vYRaqeoLjZU=@protonmail.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.3 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: On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill = wrote: >=20 >=20 > On 12/5/23 23:23, waffl3x wrote: >=20 > > Does CWG2834 effect this weird edge case? >=20 >=20 > 2834 affects all partial ordering with explicit object member functions; Both in relation to each other, and to iobj and static member functions? > currently the working draft says that they get an additional fake object > parameter, which is clearly wrong. Yeah, that's really weird. I was under the impression that's how static member functions worked, I didn't realize it was also how it's specified for xobj member functions. I still find it weird for static member functions. I guess I'll have to study template partial ordering, what it is, how it's specified and whatnot. I think I understand it intuitively but not at a language law level. > > I couldn't quite grasp the > > standardese so I'm not really sure. These are a few cases from a test > > that I finalized last night. I ran this by jwakely and he agreed that > > the behavior as shown is correct by the standard. I'll also add that > > this is also the current behavior of my patch. > >=20 > > template concept Constrain =3D true; > >=20 > > inline constexpr int iobj_fn =3D 5; > > inline constexpr int xobj_fn =3D 10; > >=20 > > struct S { > > int f(Constrain auto) { return iobj_fn; }; > > int f(this S&&, auto) { return xobj_fn; }; > >=20 > > int g(auto) { return iobj_fn; }; > > int g(this S&&, Constrain auto) { return xobj_fn; }; > > }; > > int main() { > > S s{}; > > s.f (0) =3D=3D iobj_fn; >=20 >=20 > Yes, the xobj fn isn't viable because it takes an rvalue ref. >=20 > > static_cast(s).f (0) =3D=3D iobj_fn; >=20 >=20 > Yes, the functions look the same to partial ordering, so we compare > constraints and the iobj fn is more constrained. >=20 > > s.g (0) =3D=3D iobj_fn; >=20 >=20 > Yes, the xobj fn isn't viable. >=20 > > static_cast(s).g (0) =3D=3D xobj_fn; >=20 >=20 > Yes, the xobj fn is more constrained. >=20 > Jason It's funny to see you effortlessly agree with what took me a number of hours pondering. So just to confirm, you're also saying the changes proposed by CWG2834 will not change the behavior of this example? Alex