<div dir="ltr"><div>To illustrate my question below, here are three publicly modified entities: a struct, an enum and an extension, whose properties lack explicit access modifiers:</div><div><br></div><div>    public struct Car {</div><div>        var wheel: [Wheel]</div><div>        var licensePlate: String</div><div>       </div><div>        func combust() { ... }</div><div>    }</div><div>    </div><div>    public enum Wheel {</div><div>        case big</div><div>        case small</div><div>        </div><div>        var revolutionDistance: Double { ... }</div><div>    }</div><div><br></div><div>    public extension Car {</div><div>        func park() { ... }</div><div>    }</div><div><br></div><div>The default access level for every member is `internal` for all members of an original type. Therefore both `combust()` and `revolutionDistance` are publicly inaccessible. For extensions, this is different, `park()` _is_ publicly accessible (as would be computed properties if it had any) because the extension is marked `public`. There&#39;s no option to modify an enum&#39;s cases individually (nor should there be), they&#39;re inherently linked to the enum&#39;s access level.</div><div><br></div><div>When modifying any of the entities to `private`, their members become inaccessible by association. If a type isn&#39;t accessible, neither are its members. Thus for the `private` case, the behavior feels more like what the extension modifier did in the first place. </div><div><br></div><div>Not immediately apparent from this example is that the struct has an implicit constructor (lacking any explicit ones), whose access level also defaults to `internal`. This means the Car-struct can&#39;t be constructed outside of its defining module, until we create an explicit initializer with the `public` access modifier.</div><div><br></div><div># Problems</div><div>The current approach is very verbose for any kind of access modification. Public structs that are intended to expose their members, require explicitly marked `public` modifiers everywhere. Consider the case where you want to expose a previously hidden (internal or private) type, you need to modify every individual member. Except if you&#39;re modifying an extension, in that case you only need to modify in one place. This means that conceptually, putting a `public` or `private` modifier on a type behaves differently from putting one one an extension, with regard to a type&#39;s members, which can lead to confusion (and has in my case, and with several fellow developers).</div><div><br></div><div># Idea</div><div>What if the default access level were chosen differently? Instead of being `internal` by default, or `private` by association, what if the _type-level_ access modifier would determine the default for _all_ members, unless explicitly modified, including `public` and to-be-introduced ones?</div><div><br></div><div>This would...</div><div>1. equalize the conceptual behavior between access levels of an original type and the ones of their extensions.</div><div>2. greatly reduce verbosity on members due to explicit access level modifiers.</div><div>3. make it easier to modify the access level of an entire type, without requiring modification of individual members.</div><div>4. reduce the requirement of public constructors where they would match the implicit ones.</div><div>5. still allow exceptions on an individual level</div><div><br></div><div>What do you think?</div><div>Regards,</div><div>Eric-Paul</div><div><br></div><div>--</div><div>Notes:</div><div>* I&#39;m using the word &#39;entity&#39; to lump types and extensions together under one term. There must be a better term, please do share!</div><div>* My examples are based off of my experience with Swift 2.2, even though I believe the concepts still apply in 2.3 and the 3.0-beta.</div><div>* Protocols don&#39;t allow access modification on individual members, of course, similar to an enum&#39;s cases.</div><div>* Didn&#39;t find any similar topics in the [commonly rejected list](<a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a>)</div><div>* There&#39;s a [newly accepted proposal](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#proposed-solution">https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#proposed-solution</a>) that adds `fileprivate` as a fourth access level modifier.</div><div><br></div><div>Other discussions about access levels, yet not what I was looking for:</div><div>* [Default access control / Access control blocks] (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013683.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013683.html</a>)</div><div>* [Access modifier blocks] (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html</a>)</div></div>