[PATCH RFA (libstdc++)] c++: partial ordering of object parameter [PR53499]

Jason Merrill jason@redhat.com
Wed Dec 6 04:36:29 GMT 2023


On 12/5/23 23:23, waffl3x wrote:
> Does CWG2834 effect this weird edge case?

2834 affects all partial ordering with explicit object member functions; 
currently the working draft says that they get an additional fake object 
parameter, which is clearly wrong.

> 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.
> 
> template<typename T> concept Constrain = true;
> 
> inline constexpr int iobj_fn = 5;
> inline constexpr int xobj_fn = 10;
> 
> struct S {
>    int f(Constrain auto) { return iobj_fn; };
>    int f(this S&&, auto) { return xobj_fn; };
> 
>    int g(auto) { return iobj_fn; };
>    int g(this S&&, Constrain auto) { return xobj_fn; };
> };
> int main() {
>    S s{};
>    s.f (0)                   == iobj_fn;

Yes, the xobj fn isn't viable because it takes an rvalue ref.

>    static_cast<S&&>(s).f (0) == iobj_fn;

Yes, the functions look the same to partial ordering, so we compare 
constraints and the iobj fn is more constrained.

>    s.g (0)                   == iobj_fn;

Yes, the xobj fn isn't viable.

>    static_cast<S&&>(s).g (0) == xobj_fn;

Yes, the xobj fn is more constrained.

Jason



More information about the Libstdc++ mailing list