On Tuesday, December 5th, 2023 at 9:36 PM, Jason Merrill <ja...@redhat.com>
wrote:
>
>
> 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;
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.
> >
> > 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
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
