c# - 为什么 C# 不支持 Protected 和 Internal 可访问性的交集？

Question

protected 内部:

protected 和internal 可访问性的联合(这比protected 或internal 的限制更少单独)

The CLR has the concept of intersection of protected and internal accessibility, but C# does not support this.

所以我的问题是:

省略这个访问修饰符是什么意思，有具体原因吗？那么为什么 C# 不应该支持它呢？

Answer 1

更新:C#7.2 使用访问修饰符 private protected 引入了这一点，这在某些方面似乎是错误的，但确实避免了我在下面描述的许多潜在的混淆，所以这也许是最好的一群坏人。

就我个人而言，我已经多次想要这个了。有时会在程序集中将一个类和一个或多个从它派生的类公开为 public，有时基类的某些成员仅由那些派生类使用，不应该暴露给其他程序集中的 protected 类(通常是构造函数，以防止其他程序集具有从它派生的类)。

当然，尽可能严格地定义您的访问权限总是好的，因此 protected 和 internal 的交集正是这里所需要的。

相反，我不得不通过声明成员 internal 来拼凑它。现在我的代码中可能存在错误，如果我使用允许我使用该交集的语言，这些错误就不会存在。

但是，请考虑不利因素。

实际上，对于 protected internal 给出 protected 和 internal 联合的方式存在一些混淆。根据此类网站上的问题判断，这可能是最容易被误解的访问。

我们应该怎么调用它？ 内部保护？您能想象人们多久会把它与 protected internal 混淆吗？我们希望有更明确的区别，我们希望 internal protected 也有同样的区别(因为我们仍然增加了混淆的可能性)。这不是一个无法回答的问题，但减少关键字的数量也是一个好主意。

即使找到了命名问题的完美答案，引入另一个级别的访问权限所带来的混淆的可能性并没有完全消除。

因此，考虑到这一点，让我们再次看看上行空间。我们不再需要通过使用 internal 来计算我们需要它的时间，从而减少因不恰本地使用此类成员而导致的错误。好的，这种情况多久出现一次，这些错误实际出现的可能性有多大？确实不经常，也不太可能。

因此，总的来说，虽然我确实发现自己偶尔希望 C# 有这个，但片刻的停顿通常让我很高兴他们没有。