First, let's start with requires
expressions. The section on the behavior of a requires
expression has nothing special to say about the access controls of its component expressions. Similarly, the section on access controls says nothing in particular about requires
expressions. In particular, there is [class.access]/4, which says:
Access control is applied uniformly to all names, whether the names are referred to from declarations or expressions.
Given this, it seems quite clear that requires
expressions don't need special rules. If you use a requires
expression in a context which has access to some name, then the requires
expression has access to that name. Otherwise, it cannot access the name.
So what of concept
s themselves? Well, that's simple. [temp.concept]/3 tells us:
A concept-definition shall appear at namespace scope.
concept
s are therefore global definitions; they can't be members of a class. So they cannot have access due to being a class member. friend
can only specify functions or classes, and concept
s are neither. So a concept
cannot have access due to being a friend.
concept
s are evaluated using special logic, defined in [temp.names]/8:
A concept-id evaluates to true if the concept's normalized constraint-expression is satisfied ([temp.constr.constr]) by the specified template arguments and false otherwise.
There is nothing in the rules laid down in [temp.constr.constr] which gives such evaluation any special access controls.
Therefore, any requires
expressions used as part of a concept
declaration use the global context for determining whether they can access names. That is, they can only ever use public
interfaces.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…