[swift-evolution] [Proposal] Protected Access Level

[Rod Brown]

Brent,

You make a very good point about the fact internal is not necessarily the same as subclass, something I hadn’t considered.

I think that the level of exposure these APIs then get - ultimately Public within frameworks - is too unrestricted. At least in Objective-C, we can vet the headers to break classes into separate sections where we don’t disclose certain headers to show something by default. Can we think of a way to allow opt-in access?

This ultimately gets into one of my major sore points with Swift: Framework Generated Headers suck. The Framework story for Swift seems shockingly ill conceived at this time. I could never imagine Apple shipping a framework with the current Framework setup… but I’m going into the weeds...

-Rod


> On 30 May 2016, at 10:03 AM, Brent Royal-Gordon <brent at architechies.com> wrote:
> 
>> 1. Methods and properties that only subclasses must access, but other code has no business updating. An example of this UIGestureRecognizer. State machine type access is something where external items should not access, but internal state may require the rights to update.
> 
> But again, "external" does not necessarily mean "non-subclass", and "internal" does not necessarily mean "subclass". A particular subclass might not require access, and a helper type/function might require access.
> 
> This insight—that the type graph doesn't always reflect the boundaries of concerns—is the very basis of Swift's current access control design. It's the reason why `private` (soon to become `fileprivate`) doesn't grant visibility to extensions on the same type in different files, but *does* grant it to extensions on different types in the same file. This is an important innovation in Swift's access control design, and we shouldn't ignore it when we're thinking about `protected`.
> 
> -- 
> Brent Royal-Gordon
> Architechies
>