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?

Reply via email to