在哪些访问控制上下文中评估了概念？ [英] In which access control context are evaluated concepts?
问题描述
该问题是对此一个
未实例化概念（[temp.spec]）。
[注：表示概念专业化的id表达式被评估为表达式（[expr.prim.id]）。 [...]]
A concept is not instantiated ([temp.spec]). [ Note: An id-expression that denotes a concept specialization is evaluated as an expression ([expr.prim.id]). [...]]
因此，由于可访问性，命名概念专门化的表达式可能具有不同的值。
So maybe an expression that name a concept specialization can have different value because of accessibility.
如果是这种情况，我想知道在哪种情况下可以对表达式进行评估：
If it were the case, I wonder in which context would be evaluated the expression:
-
概念定义的上下文；
The context of the concept definition;
表达式的上下文；
将表达式的上下文递归应用于概念定义中出现的概念表达式？
The context of the expression recursively applied to concepts expression appearing in concepts definition?
例如，可能是 A :: b2 和 A :: b2_rec 的值？
template<class T>
concept has_private = requires(){ &T::private_;};
template<class T>
concept has_private_rec = has_private<T>;
class B{
int private_;
friend class A;
};
inline constexpr bool b1 = has_private<B>;//I expects false
inline constexpr bool b1_rec = has_private_rec<B>;//I expects false
class A{
static constexpr bool b2 = has_private<B>; //?
static constexpr bool b2_rec = has_private_rec<B>; //?
};
注意Clang实验概念和gcc概念TS实现会为b1和b1_rec产生编译错误，但b2和b2_rec是真的；
Note Clang experimental concepts and gcc concepts TS implementation produce compilation error for b1 and b1_rec, but b2 and b2_rec are true;
推荐答案
首先，让我们从 requires 表达式开始。 关于要求的行为的部分表达式对于其组件表达式的访问控制没有什么特别要说的。同样，关于访问控制的部分没有特别说明 requires 表达式。特别是，有 [class.access] / 4 ，表示：
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.
鉴于此，很显然要求表达式不需要特殊的规则。如果在可以访问某些名称的上下文中使用 requires 表达式，则 requires 表达式可以访问该名称名称。否则，它将无法访问该名称。
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.
那么概念本身又是什么呢？好吧，很简单。 [temp.concept] / 3 告诉我们：
So what of concepts themselves? Well, that's simple. [temp.concept]/3 tells us:
概念定义应出现在命名空间范围内。
A concept-definition shall appear at namespace scope.
friend 只能指定函数或类，而 concept 都不能。因此，概念由于是朋友而无法访问。
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.
概念 s使用 [temp.names] / 8 ：
如果指定的模板参数满足概念的规范化约束表达式（[temp.constr.constr]），则概念ID的值为true
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.
[temp.constr.constr] ，它为这种评估提供了任何特殊的访问控制。
There is nothing in the rules laid down in [temp.constr.constr] which gives such evaluation any special access controls.
因此，任何<$ c在概念声明中使用的$ c>要求表达式使用全局上下文确定它们是否可以访问名称。也就是说，他们只能使用 public 接口。
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.
这篇关于在哪些访问控制上下文中评估了概念？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
