Swift Access Control - I don't need protectin'

There has been a lively debate about the absence of protected (or some other keyword) in Swift (David Owen's stands out as a reasoned request and Apple's response (oh and can we take a minute to enjoy the fact that there actually is an Apple response?)). In short, I find Apple's arguments compelling. They can be distilled into two simple points (there is a third about potential complexities around extensions, but I think these are less compelling and their job to solve)

• Protected conflates access control with inheritance, making access control harder to reason about
• It offers no real protection... you can just sub-class and provide public thunking methods

As a Java from 1.0... I have to say I agree with these two points. I've seen 100's of cases of people working around protected, allowing something that was supposed to be restricted to an expected small set of sub-classes to become a dependency throughout a large code base. 

Protected provides a perceived safe middle ground... I can expose it, but consumers can't abuse it. It stops me making a real decision... should this be available to all, just to those working within the module, or just this one class? At the end of my time as a java developer I had come to the conclusion that things would either be public, private or package private. Sound familiar? 

There are certainly times I would have liked to make something protected. I would like to make the class less complex for consumers (driving me towards private), but enable re-use by sub-classers (driving me towards public). Do your-future-self a favour. Make it private if you intend the class to be used outside your organisation. Within your organisation, make it internal.