On Tue, 14 Jan 2025, Jason Merrill wrote: > On 1/10/25 1:36 PM, Patrick Palka wrote: > > On Tue, 1 Oct 2024, Patrick Palka wrote: > > > On Mon, 16 Sep 2024, Patrick Palka wrote: > > > > On Thu, 30 Nov 2023, Patrick Palka wrote: > > > > > On Fri, 3 Nov 2023, Patrick Palka wrote: > > > > > > On Tue, 3 May 2022, Jason Merrill wrote: > > > > > > > > > > > > > On 5/2/22 14:50, Patrick Palka wrote: > > > > > > > > Currently when checking the constraints of a class template, we > > > > > > > > do so in > > > > > > > > the context of the template, not the specialized type. This is > > > > > > > > the best > > > > > > > > we can do for a primary template since the specialized type is > > > > > > > > valid > > > > > > > > only if the primary template's constraints are satisfied. > > > > > > > > > > > > > > Hmm, that's unfortunate. It ought to be possible, if awkward, to > > > > > > > form the > > > > > > > type long enough to check its constraints. > > > > > > > > > > > > (Sorry, lost track of this patch...) > > > > > > > > > > > > Seems doable, but I'm not sure if would make any difference in > > > > > > practice? > > > > > > > > > > > > If the access context during satisfaction of a primary class > > > > > > template's > > > > > > constraints is the specialization rather than the primary template, > > > > > > then that should only make a difference if there's some friend > > > > > > declaration > > > > > > naming the specialization. But that'd mean the specialization's > > > > > > constraints had to have been satisfied at that point, before the > > > > > > friend > > > > > > declaration went into effect. So either the constraints don't > > > > > > depend on > > > > > > the access granted by the friend declaration anyway, or they do and > > > > > > the > > > > > > program is ill-formed (due to either satifaction failure or > > > > > > instability) IIUC. > > > > > > > > > > > > For example, I don't think an adapted version of the testcase > > > > > > without a > > > > > > partial specialization is valid, regardless of whether the access > > > > > > context > > > > > > during satisfaction of A<B> is A<B> or just A: > > > > > > > > > > > > template<class T> > > > > > > concept fooable = requires(T t) { t.foo(); }; > > > > > > > > > > > > template<fooable T> > > > > > > struct A { }; > > > > > > > > > > > > struct B { > > > > > > private: > > > > > > friend struct A<B>; // satisfaction failure at this point > > > > > > void foo(); > > > > > > }; > > > > > > > > > > > > template struct A<B>; > > > > > > > > > > ... so in light of the above, I wonder if the original patch can go in > > > > > as-is? > > > > > > > > Ping. > > > > > > Ping. > > > > Ping. > > As I commented on the PR, we probably want to stop considering friendship at > all in this testcase, so the value of fooable<T> does not depend on where it > appears. The resolution for 2589 is still under review, but there seems to be > general agreement on that point. > > Sorry I didn't previously point to that in this thread.
Whoops, I remember seeing that comment but forgot about it as well (Bugzilla is down for me so I can't reply to the PR ATM). Ignoring context/friendship when checking an atomic constraint normalized from a concept-id such as fooable<T> seems reasonable, but I'm surprised that the latest revision of the CWG 2589 PR would also make us ignore friendship for "inline/non-shareable" atomic constraints, e.g. template<class> struct A; template<class T> requires requires(T t) { t.foo(); } struct A<T> { }; Here the atomic constraint is unique to where it was written, so it seems we might as well consider friendship in this case?