On 12/6/23 01:02, waffl3x wrote:
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.
Right, adding it to static member functions was a recent change, and IMO
also 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
It's funny to see you effortlessly agree with what took me a number of
hours pondering.
Well, I've also been thinking about this area, thus the patch. :)
So just to confirm, you're also saying the changes proposed by CWG2834
will not change the behavior of this example?
I'm saying the changes I'm advocating for CWG2834 (the draft you saw on
github is not at all final) will establish that behavior.
Jason
