<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">The only point that judges the proposal on its merits would be the first one, and I would personally be happy to have that discussion.<br class=""><div class="">
<br class="Apple-interchange-newline"><span style="color: rgb(0, 0, 0); font-family: 'Lucida Grande'; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: 2; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-stroke-width: 0px; display: inline !important; float: none;" class="">Félix</span>
</div>
<br class=""><div><blockquote type="cite" class=""><div class="">Le 22 juil. 2016 à 10:14:13, Jose Cheyo Jimenez via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; a écrit :</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="Apple-interchange-newline"><br class="">On Jul 22, 2016, at 3:34 AM, Eric-Paul Lecluse via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; wrote:<br class=""><br class=""></div><blockquote type="cite" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div dir="ltr" class=""><div class="">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 class=""><br class=""></div><div class="">&nbsp; &nbsp; public struct Car {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; var wheel: [Wheel]</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; var licensePlate: String</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; func combust() { ... }</div><div class="">&nbsp; &nbsp; }</div><div class="">&nbsp; &nbsp;&nbsp;</div><div class="">&nbsp; &nbsp; public enum Wheel {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; case big</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; case small</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp;&nbsp;</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; var revolutionDistance: Double { ... }</div><div class="">&nbsp; &nbsp; }</div><div class=""><br class=""></div><div class="">&nbsp; &nbsp; public extension Car {</div><div class="">&nbsp; &nbsp; &nbsp; &nbsp; func park() { ... }</div><div class="">&nbsp; &nbsp; }</div><div class=""><br class=""></div><div class="">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's no option to modify an enum's cases individually (nor should there be), they're inherently linked to the enum's access level.</div><div class=""><br class=""></div><div class="">When modifying any of the entities to `private`, their members become inaccessible by association. If a type isn'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.&nbsp;</div><div class=""><br class=""></div><div class="">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't be constructed outside of its defining module, until we create an explicit initializer with the `public` access modifier.</div><div class=""><br class=""></div><div class=""># Problems</div><div class="">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'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's members, which can lead to confusion (and has in my case, and with several fellow developers).</div><div class=""><br class=""></div><div class=""># Idea</div><div class="">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></div></blockquote><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><span style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I don't think this is going fly:</span><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">- internal is the default because the team wants any public API to be explicit.&nbsp;</div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">- There was a rejected proposal (119?) that tried to make extensions work just like types.&nbsp;</div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">- This is a breaking change and we are out of time for swift3</div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">- What you want is already offered by public extensions. (Some people find this confusing but it looks like this is stay in swift 3).&nbsp;</div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class=""><br class=""></div><div class="">This would...</div><div class="">1. equalize the conceptual behavior between access levels of an original type and the ones of their extensions.</div><div class="">2. greatly reduce verbosity on members due to explicit access level modifiers.</div><div class="">3. make it easier to modify the access level of an entire type, without requiring modification of individual members.</div><div class="">4. reduce the requirement of public constructors where they would match the implicit ones.</div><div class="">5. still allow exceptions on an individual level</div><div class=""><br class=""></div><div class="">What do you think?</div><div class="">Regards,</div><div class="">Eric-Paul</div><div class=""><br class=""></div><div class="">--</div><div class="">Notes:</div><div class="">* I'm using the word 'entity' to lump types and extensions together under one term. There must be a better term, please do share!</div><div class="">* 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 class="">* Protocols don't allow access modification on individual members, of course, similar to an enum's cases.</div><div class="">* Didn't find any similar topics in the [commonly rejected list](<a href="https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md" class="">https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md</a>)</div><div class="">* There's a [newly accepted proposal](<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md#proposed-solution" class="">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 class=""><br class=""></div><div class="">Other discussions about access levels, yet not what I was looking for:</div><div class="">* [Default access control / Access control blocks] (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013683.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160328/013683.html</a>)</div><div class="">* [Access modifier blocks] (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160613/020968.html</a>)</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></div><span style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">_______________________________________________</span><br style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: LucidaGrande; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>