`private` and `protected` access

[josh11b]

Summary of issue:

What precisely are the rules that determine what has access to members with private or protected access modifiers?

Here are some questions that I don't think are addressed by the current design:

• Can methods in an adapter of C access protected members of C?
• Is access enforced only on name lookup and resolution, or is it affected by member binding? (For example, does access to a protected member of a base class require it be applied to an object or value of the current derived class?)
• Can a function on C(T) access private & protected members of C(U)?
• If Derived(T) extends Base(T), can Derived(T) access protected members of Base(U)?

Context:

Classes: Access control documents the currently accepted design for access control modifiers. It documents the basics such as:

• private means only accessible to members of the class and any friends.
• Protected members may only be accessed by members of this class, members of derived classes, and any friends.

[josh11b]

Further context: Proposal #3720: Member binding operators defines how the members of types (including classes and interfaces) are their own values that are passed as input to the member binding operators. This allows the members to be passed separately from the objects or values they will be bind to, and that member binding might happen in a function with different access than the one that performed the member lookup.

Further context: The current design of specialization of generic classes does not allow Carbon classes to have different definitions for different arguments. Instead, specialization happens purely through impl specialization.

These two aspects of Carbon's design suggest an approach to me:

• Access for a member is determined entirely when the member name is looked up and resolved. This has some advantages:
  • It is a succinct and clear rule, which is good for language simplicity and teaching.
  • It would be less code to implement in the toolchain.
  • It aligns well with the approach from Member binding operators #3720 .
• We generally ignore the arguments to generic types when considering access, except that a friend declaration can specify that only a specific has access (by saying friend Vector(MyClass); instead of friend Vector;).
  • This is motivated by our specialization approach where the same source code is used for all argument values.

So my proposed answers to the questions are:

1. Methods in an adapter of C can not access protected members of C, until we have a motivating use case.
2. Access enforced only on name lookup and resolution.
3. A function on C(T) can access private & protected members of C(U).
4. If Derived(T) extends Base(T), Derived(T) can access protected members of Base(U).

(I feel strongest about 2, then 3, then 4, and least strong about 1.)