In which access control context are concepts evaluated?

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 concepts themselves? Well, that’s simple. [temp.concept]/3 tells us:

A concept-definition shall appear at namespace scope.

concepts 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 concepts are neither. So a concept cannot have access due to being a friend.

concepts 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.

Leave a Comment