On 1/14/25 9:46 PM, Patrick Palka wrote:
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?
Yeah, a reply on the list made the same point, there should be further
revision.
Jason
