https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104111
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Blocks| |67491
--- Comment #5 from Jason Merrill <jason at gcc dot gnu.org> ---
(In reply to Patrick Palka from comment #3)
> > because concept-id evaluation shall not depend on the context.
>
> One consequence of making this change to concept-id evaluation would be that
> for:
>
> template<class T> void f() requires (!C<T>);
>
> during constraint checking for say f<int>(), we no longer evaluate C<int>
> (as part of evaluation of the atomic constraint !C<T>) in the access context
> of f, which seems surprising to me.
>
> CC'ing Jason for guidance.
This issue was discussed on the CWG mailing list back in 2018, but seems never
to have made it to the issues list. There was general agreement at the time
that access should be checked in the lexical context of the atomic constraint,
as with other expressions; this does indeed have the consequence that you
mention. Which means that since we don't have class-scope concepts, any
constraints that need to depend on access control need to be written directly
in the requires-clause rather than through a concept. Or just give up on
trying to express constraints that depend on access.
An alternative fix for this bug would be to include the evaluation context in
the satisfaction cache.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues
