[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