Re: [PATCH] c++: implicit guides should inherit class constraints [PR104873]

[Jason Merrill <jason@redhat.com>]

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