On 12/20/23 12:00, Patrick Palka wrote:
On Fri, 1 Apr 2022, Jason Merrill wrote:

On 4/1/22 11:17, Patrick Palka wrote:
An implicit guide already inherits the (rewritten) constraints of the
constructor.  Thus it seems natural that the guide must also inherit
the constraints of the class template, since a constructor's constraints
might assume the class's constraints are satisfied, and therefore
checking these two sets of constraints "out of order" may result in hard
errors as in the first testcase below.

This patch makes implicit guides inherit the constraints of the class
template (even for unconstrained constructors, and even for the copy
deduction candidate).

In passing, this patch gives implicit guides a trailing return type
since that's how they're depicted in the standard (e.g.
[over.match.class.deduct]/6); this changes the order of substitution
into implicit guides in a probably negligible way, especially now that
they inherit the class constraints.

The parameter_mapping_equivalent_p change is to avoid an ICE in the last
testcase below (described within), reduced from a cmcstl2 testsuite ICE.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look like
the right approach?

I don't think so, given the testcases below.

Maybe fn_type_unification should check formation of the return type of a
deduction guide before constraints?  In general, whichever order you do things
in, it'll be wrong for some testcase or other.

Makes sense..  Though I notice the resolution of CWG2628 goes the
direction of propagating the class's constraints and seems to have been
approved in November.  I wonder how that discussion went wrt your
alternative resolution of first checking the return type during
deduction?  Shall we follow suit with the approved resolution (and
therefore this patch) for GCC 14?

Hmm, it seems like I failed to ever actually make that suggestion, so I suppose let's go ahead with your patch.

I wonder about adding a joust warning for this case, to help people understand why their deduction guide is being ignored. But I'm not sure that real code would actually write deduction guides with signatures similar enough to constructors that we consider which one is more constrained, so it's probably not important.

Jason

Reply via email to