<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Sat, Jul 16, 2016 at 6:10 PM, David Hart <span dir="ltr"><<a href="mailto:david@hartbit.com" target="_blank">david@hartbit.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>This proposal really confuses me. Two comments:</div><div><br></div><div>1) With the proposal, we loose the ability to use access modifiers on extensions as a way of grouping members by access. That's a huge loss for me.</div></div></blockquote><div><br></div><div>You lose the ability to group public members only. That part is intentional, so that only methods declared with `public func` are public.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div></div><div>2) If we adopt the proposal, I now have no idea what explicit access modifiers on extensions do.</div></div></blockquote><div><br></div><div>I propose keeping explicit access modifiers because previous comments on this list have said that it's useful for grouping members by access. You can continue to use extensions to group fileprivate members of an internal type, or internal members of a public type.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div>More generally, I don't understand this proposal as it's trying to apply the same access modifier rules on extensions as for types but extensions are not types. They are just a declaration for extending types which already have an access level.</div><div><div><div><br>On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><div dir="ltr">With the impending withdrawal of SE-0119 and the closing window for (most) source-breaking changes, I thought I'd draft up a proposal to address some of the key points raised in that discussion.<div><br></div><div>The proposed changes are deliberately limited in scope to rationalizing access modifier rules without adding any new facilities (such as conformances of lower visibility than the type), which might be more appropriate for the Swift 4 timeline.</div><div><br></div><div>I hope this will prove satisfactory to the community :)</div><div><br></div><div><br></div><div><h1 style="font-size:32px;margin-right:0px;margin-bottom:16px;margin-left:0px;line-height:1.5;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';margin-top:0px!important">Harmonize access modifiers for extensions</h1><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px"><li>Proposal: <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">SE-XXXX</a></li><li style="margin-top:0.25em">Author: <a href="https://github.com/xwu" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">Xiaodi Wu</a></li><li style="margin-top:0.25em">Status: <span style="font-weight:600">Awaiting review</span></li><li style="margin-top:0.25em">Review manager: TBD</li></ul><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#introduction" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Introduction</h2><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">During discussion of <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0119-extensions-access-modifiers" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">SE-0119</a>, the community articulated the view that access modifiers for extensions were and should continue to be subject to the same rules as access modifiers for types. Unfortunately, it is not factually true today; this proposal aims to make it so.</p><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">Swift-evolution threads:</p><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px"><li><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/022144.html" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank">[Proposal] Revising access modifiers on extensions</a></li><li style="margin-top:0.25em">[More to be added here]</li></ul><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#motivation" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Motivation</h2><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">Consider the following:</p><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:16px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)"><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;border:0px;display:inline;overflow:visible;line-height:inherit;word-wrap:normal">public struct foo {
func frobnicate() { } // implicitly internal
}
public extension foo { }
public struct bar { }
public extension bar {
func frobnicate() { } // implicitly public, according to SE-0025
}
</code></pre><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">According to SE-0025, a method moved from the body of a public struct into a public extension becomes public without modification. This is surprising behavior contrary to Swift's general rule of not exposing public API by default.</p><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">Furthermore, SE-0025 now permits the owner of a type to design access for members as though the type will have a higher access level than it currently does. For example, users will be able to design <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">public</code> methods inside an <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">internal</code>type before "flipping the switch" and making that type <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">public</code>. The same approach is prohibited by SE-0025 for extensions, although conceptually it need not be.</p><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#proposed-solution" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Proposed solution</h2><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">The proposed solution is to change access modifier rules for extensions with the following effect: if any method (or computed property) declared within the body of a type at file scope is moved without modification into the body of an extension in the same file, the move will not change its accessibility.</p><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">In code:</p><pre style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;margin-top:0px;margin-bottom:16px;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;color:rgb(51,51,51)"><code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;padding:0px;margin:0px;background-color:transparent;border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px;border:0px;display:inline;overflow:visible;line-height:inherit;word-wrap:normal">struct foo {
// Any method declared here...
}
extension foo {
// ...should have the same visibility when moved here.
}
</code></pre><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">This implies that public API commitments will need to be annotated as <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">public</code> at declaration sites inside an extension just as it must be at declaration sites inside types.</p><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#detailed-design" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Detailed design</h2><ol style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px"><li>Declarations inside the extension will, like declarations inside types, have a default access level of <code style="font-family:Consolas,'Liberation Mono',Menlo,Courier,monospace;font-size:14px;padding:0.2em 0px;margin:0px;background-color:rgba(0,0,0,0.0392157);border-top-left-radius:3px;border-top-right-radius:3px;border-bottom-right-radius:3px;border-bottom-left-radius:3px">internal</code>.</li><li style="margin-top:0.25em">The compiler should not warn when a broader level of access control is used for a method (or computed property, etc.) declared within an extension with more restrictive access. This allows the owner of the extension to design the access level they would use for a method if the type or extension were to be made more widely accessible.</li><li style="margin-top:0.25em">An extension declared without an explicit access modifier will have the same access level as the type being extended.</li><li style="margin-top:0.25em">An extension declared without protocol conformance may optionally use an explicit access modifier to provide an upper bound for the visibility of its members.</li></ol><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#alternatives-considered" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Alternatives considered</h2><ul style="padding-left:2em;margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px"><li>One alternative, still open for consideration, is to eliminate #4 and disallow explicit access modifiers on extensions. As an advantage, this would clarify the mental model that extensions are not their own entities, as they cannot be referred to by name and have no runtime representation. As a disadvantage, extensions cease to be an access modifier grouping construct, which some users really like.</li></ul><h2 style="margin-top:1em;margin-bottom:16px;line-height:1.5;font-size:24px;padding-bottom:0.3em;border-bottom-width:1px;border-bottom-style:solid;border-bottom-color:rgb(238,238,238);color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol'"><a href="https://github.com/xwu/swift-evolution/tree/harmonize-access-modifiers#acknowledgments" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1" target="_blank"></a>Acknowledgments</h2><p style="margin-top:0px;margin-bottom:16px;color:rgb(51,51,51);font-family:-apple-system,BlinkMacSystemFont,'Segoe UI',Roboto,Helvetica,Arial,sans-serif,'Apple Color Emoji','Segoe UI Emoji','Segoe UI Symbol';font-size:16px">Thanks to all discussants on the list, especially Adrian Zubarev and Jose Cheyo Jimenez.</p></div></div>
</div></blockquote></div></div><blockquote type="cite"><div><span>_______________________________________________</span><span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></span></div></blockquote></div></blockquote></div><br></div></div>