<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="">+1. Makes sense this way.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jul 18, 2016, at 9:50 AM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">All righty, thanks for all of your feedback. I've worked on revising the proposal this evening, re-reading previous documents and messages and re-analyzing what people meant. I think Jose is absolutely right in the end, and the proposal has turned out like he suggested. Here is the current draft below:<div class=""><div class=""><br class=""></div><div class=""><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" class="">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" class=""><li style="" class="">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" class="">SE-XXXX</a></li><li style="margin-top:0.25em" class="">Author: <a href="https://github.com/xwu" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">Xiaodi Wu</a></li><li style="margin-top:0.25em" class="">Status: <span style="font-weight:600" class="">Awaiting review</span></li><li style="margin-top:0.25em" class="">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'" class=""><a id="user-content-introduction" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#introduction" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></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" class="">During discussion of <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0119-extensions-access-modifiers.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">SE-0119</a>, some voiced concern that writing <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" class="">public extension</code> increases the default access level for members declared within that extension, whereas writing <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" class="">public class</code> or <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" class="">public struct</code> does not do the same.</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" class="">This behavior is explained as follows: since extensions have no runtime representation and are not first-class entities, access modifiers on extensions serve as a shorthand to set the default access level for members. Certain members of the community have indicated that such behavior makes extensions a natural grouping construct.</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" class="">A general principle of Swift, recently strengthened by proposals such as <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0117-non-public-subclassable-by-default.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">SE-0117</a>, has been that public API commitments should require explicit opt-in. Given the different behavior of classes and structs, the fact that extensions allow public methods to be declared without spelling out <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" class="">public</code> at the declaration site has been called "confusing" or "odd."</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" class="">The aim of this proposal is to, in as conservative a manner as possible, require explicit use 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" class="">public</code> for public methods declared inside any extension.</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" class="">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" class=""><li style="" class=""><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" class="">[Proposal] Revising access modifiers on extensions</a></li><li style="margin-top:0.25em" class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024224.html" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">[Review] SE-0119: Remove access modifiers from extensions</a></li><li style="margin-top:0.25em" class=""><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160711/024522.html" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">[Draft] Harmonize access modifiers for extensions</a></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'" class=""><a id="user-content-motivation" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#motivation" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></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" class="">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)" class=""><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" class="">public struct foo {
func frobnicate() { } // internal
}
public extension foo { }
public struct bar { }
public extension bar {
func frobnicate() { } // public
}
</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" class="">This outcome is explained by rules regarding access modifiers specifically on extensions <a href="https://developer.apple.com/library/ios/documentation/Swift/Conceptual/Swift_Programming_Language/AccessControl.html" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">Swift 2</a>, which is slated for preservation in Swift 3 as detailed in <a href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/0025-scoped-access-level.md" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" class="">SE-0025</a>. However, it is arguably surprising that, of two declarations spelled identically, one leads to a public API commitment while the other does not.</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'" class=""><a id="user-content-proposed-solution" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#proposed-solution" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></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" class="">The proposed solution is to amend access modifier rules to eliminate the possibility of defaulting the access level of members declared inside an extension to <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" class="">public</code>.</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'" class=""><a id="user-content-detailed-design" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#detailed-design" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></a>Detailed design</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" class="">Amend access modifier rules as follows:</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" class="">An extension may optionally be marked with an explicit access modifier that specifies the default scope [see SE-0025]. However, such an explicit modifier <em style="" class="">must not match (or exceed) the original type's access level</em>.</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" class="">This rule would preserve the possibility of using extensions as grouping constructs. At the same time, it would (1) remove the possibility of writing <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" class="">public extension</code> to default the access level of members to <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" class="">public</code>; and (2) clarify the notion that an access modifier on an extension is a shorthand and not a way to create a first-class entity by disallowing repeating of the original type's access level.</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" class=""><em style="" class="">Explicit</em> access modifiers will continue to set the maximum allowed access within an extension, as clarified in SE-0025.</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'" class=""><a id="user-content-alternatives-considered" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#alternatives-considered" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></a>Alternatives considered</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" class="">One alternative is to eliminate explicit access modifiers on extensions altogether. As an advantage, this would further clarify the mental model that extensions are not their own first-class entities. As a disadvantage, extensions cease to be an access modifier grouping construct, which some users really like.</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'" class=""><a id="user-content-acknowledgments" class="" href="https://github.com/xwu/swift-evolution/blob/harmonize-access-modifiers/proposals/XXXX-harmonize-access-modifiers.md#acknowledgments" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none;display:inline-block;padding-right:2px;line-height:1"></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" class="">Thanks to all discussants on the list, especially Adrian Zubarev, Jose Cheyo Jimenez, and Paul Cantrell.</p></div><div class="gmail_extra"><br class=""><div class="gmail_quote"><br class=""></div><div class="gmail_quote">On Sun, Jul 17, 2016 at 11:08 AM, Xiaodi Wu <span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I understand how it works.<br class=""><br class="">By aligning access modifier rules inside extensions with those inside types, all other modifiers would continue to work as it does now (implicitly internal members would be limited by the upper bound). The only change in this respect is removing the ability to have public API without writing `public func`.<div class="HOEnZb"><div class="h5"><br class=""><div class="gmail_quote"><div dir="ltr" class="">On Sun, Jul 17, 2016 at 11:01 Adrian Zubarev via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class=""></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><p class="">I tackled it as an upper bound but highly rejected by the community. That’s exactly what my proposal was all about. An upper boundary would be more elegant, but I still see arguments ‘because it’s not a type’.</p><p class="">I could live without access modifiers on extensions in general.</p></div></div><div style="word-wrap:break-word" class=""><div class="">
<blockquote class=""><p class="">The default access modifier rule permits public methods to be written without <code class="">public func</code></p>
</blockquote>
</div></div><div style="word-wrap:break-word" class=""><div class=""><p class="">You meant this?</p>
<pre class=""><code class="">public extension SomeType {
// I don't need to write public
func foo() {}
var computed: Type {}
}
</code></pre><p class="">This applies to all access modifiers which are not optional (like internal):</p>
<pre class=""><code class="">public SomeType
fileprivate extension SomeType {
// I don't need to repeat fileprivate
func foo() {}
var computed: Type {}
}
// which is more likely `fileprivate` because it's on file scope
private extension SomeType {
// even if the inner access modifier would pretend to be private
// since the extension is on filescope, everything will be `fileprivate`
func foo() {}
var computed: Type {}
}
</code></pre><div class=""><br class="webkit-block-placeholder"></div></div><div class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><div style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class=""><br class=""></div> <br class=""> <div class=""><div style="font-family:helvetica,arial;font-size:13px" class="">-- <br class="">Adrian Zubarev<br class="">Sent with Airmail</div></div> <br class=""></div></div><div style="word-wrap:break-word" class=""><div class=""><p class="">Am 17. Juli 2016 um 17:50:31, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>) schrieb:</p> <blockquote type="cite" class=""><span class=""><div class=""><div class=""></div><div class="">
The proposal is that the access modifier for an extension will
either be removed entirely or remain as an upper bound, losing its
function as a default access modifier. The default access modifier
rule permits public methods to be written without `public func`;
this is a proposal to remove that feature because it is a source of
confusion.<br class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Sun, Jul 17, 2016 at 10:43 Adrian Zubarev via
swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>
wrote:<br class=""></div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><p class="">I still don’t catch to point here. There is no <code class="">implicit
public</code> there. It’s explicit set by the default access
modifier of extensions. It’s how they work and how they should
remain (at least as long the community want <code class="">default access
modifier</code> to exist on extensions). Disallowing setting
<code class="">public</code> on extensions when you extend a public type
makes no sense. If you want your member to be <code class="">internal</code>
like it’s in types, then remove the access modifier from extension
and all member will follow the type access modifier.</p>
</div>
</div>
<div style="word-wrap:break-word" class="">
<div class="">
<div style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">
<br class=""></div>
<br class="">
<div class="">
<div style="font-family:helvetica,arial;font-size:13px" class="">
-- <br class="">
Adrian Zubarev<br class="">
Sent with Airmail</div>
</div>
<br class=""></div>
</div>
<div style="word-wrap:break-word" class="">
<div class=""><p class="">Am 17. Juli 2016 um 17:37:02, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>) schrieb:</p>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class=""><span class="">That's a good point. I will incorporate these
into a revised draft. Only two things will change:</span>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">```</span></div>
<div class=""><span class="">public struct Foo {</span></div>
<div class=""><span class=""> // implicitly internal</span></div>
<div class=""><span class=""> func frobnicate1() { }</span></div>
<div class=""><span class="">}<br class=""></span></div>
<div class=""><span class="">public extension Foo {</span></div>
<div class=""><span class=""> // currently implicitly public</span></div>
<div class=""><span class=""> //</span></div>
<div class=""><span class=""> // depending on which alternative is
adopted,</span></div>
<div class=""><span class=""> // the proposal will either prohibit `public
extension`</span></div>
<div class=""><span class=""> // or this method will be implicitly
internal</span></div>
<div class=""><span class=""> func frobnicate2() { }</span></div>
<div class=""><span class="">}<br class=""></span></div>
<div class=""><span class="">```</span></div>
<div class=""><span class=""><br class=""></span></div>
<div class=""><span class="">```</span></div>
<div class=""><span class="">internal struct Bar {</span></div>
<div class=""><span class=""> // permitted by SE-0025 without a
warning</span></div>
<div class=""><span class=""> // this method can only be accessed within module
anyway</span></div>
<div class=""><span class=""> // because `internal struct` bounds access of its
members</span></div>
<div class=""><span class=""> public func frobnicate1() { }</span></div>
<div class=""><span class="">}<br class=""></span></div>
<div class=""><span class="">extension Bar {</span></div>
<div class=""><span class=""> // not permitted by SE-0025</span></div>
<div class=""><span class=""> //</span></div>
<div class=""><span class=""> // after proposal, this will also be permitted
without a warning</span></div>
<div class=""><span class=""> // and this method will also be accessible only
within module</span></div>
<div class=""><span class=""> public func frobnicate2() { }</span></div>
<div class=""><span class="">}</span></div>
<div class=""><span class="">```</span></div>
<div class="gmail_extra"><span class=""><br class=""></span>
<div class="gmail_quote"><span class="">On Sun, Jul 17, 2016 at 1:50 AM,
Adrian Zubarev via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span>
wrote:<br class=""></span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div style="word-wrap:break-word" class="">
<div class=""><p class="">I’m struggling to understand your proposal, can you provide some
specific code samples how it works now and what will change. The
example from the draft doesn’t help my understanding. :/</p>
</div>
<div class="">
<div style="font-family: Helvetica, Arial; font-size: 13px; margin: 0px;" class="">
<span class=""><br class=""></span></div>
<span class=""><br class=""></span>
<div class="">
<div style="font-family:helvetica,arial;font-size:13px" class="">
<span class="">-- <br class="">
Adrian Zubarev<br class="">
Sent with Airmail</span></div>
</div>
<span class=""><br class=""></span>
<div class="">
<div class=""><p class="">Am 17. Juli 2016 um 04:40:45, Xiaodi Wu via swift-evolution
(<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>) schrieb:</p>
<blockquote type="cite" class="">
<div class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote"><span class="">On Sat, Jul 16, 2016 at 7:56 PM,
Jose Cheyo Jimenez <span dir="ltr" class=""><<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>></span> wrote:<br class=""></span>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">I think you can simplify this proposal by just saying
something like this and give a couple of examples that are easy to
follow:</div>
<div class=""><br class=""></div>
<div class="">Disallow explicit public access modifier on
non-protocol-conforming type extensions.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">It took me a while to process what you're trying to say here,
but this is a good idea and would go along well with the first
draft's proposed solution. I will spell it out. (If we say that you
can use an explicit modifier only to lower the access level of
members, then `public` as an explicit modifier could be entirely
disallowed.)</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class=""><br class=""></div>
<div class="">I think if you only focus on that breaking change then the
proposal will have a good chance of getting accepted and fixing the
immediate issue of public. There is a reason why protocol
conforming extensions do not allow explicitly saying
public </div>
<div class="">`public extension Type: Protocol {}` // public not
allowed </div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">Actually, no modifiers are allowed in that scenario,
IIUC.</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class=""><br class=""></div>
<div class="">In essence we will be asking for the same behavior for
types. </div>
<div class=""><br class=""></div>
<div class="">Allowing methods declared inside extensions to have a higher
declared visibility is not a breaking change and can be introduced
later. </div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">It is a breaking change in that I am proposing that the rules
be harmonized so that the implicit default access level will be
notionally `internal` (there are follow-on benefits to this
change). That cannot be changed later.</div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">Nobody wants private extensions or implicit internal
extensions to go away. :)</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">I know that there are people who don't want it to go away.
That was why the first draft proposed keeping them, but it sounds
like it would make for an illogical system. I know that Jordan and
John have both indicated that they don't think it's worth keeping
around but don't seem to feel too strongly about it, and I think I
feel the same way (leaning towards not keeping them, but don't feel
very strongly). I will definitely feature this concern (using
extensions as access modifier groups) prominently in the proposal
and hope for a robust discussion to see how it plays out with the
community and core team.</div>
<div class=""><br class=""></div>
<div class=""><br class=""></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">
<div class="">
<div class=""><br class="">
On Jul 16, 2016, at 4:22 PM, Xiaodi Wu via swift-evolution
<<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">
<div class="gmail_extra">
<div class="gmail_quote">On Sat, Jul 16, 2016 at 6:10 PM, David
Hart <span dir="ltr" class=""><<a href="mailto:david@hartbit.com" target="_blank" class="">david@hartbit.com</a>></span> wrote:<br class="">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">This proposal really confuses me. Two comments:</div>
<div class=""><br class=""></div>
<div class="">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 class=""><br class=""></div>
<div class="">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 class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">2) If we adopt the proposal, I now have no idea what explicit
access modifiers on extensions do.</div>
</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">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 class=""><br class=""></div>
<div class=""> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div dir="auto" class="">
<div class="">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 class="">
<div class="">
<div class=""><br class="">
On 16 Jul 2016, at 20:04, Xiaodi Wu via swift-evolution
<<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class=""></div>
<blockquote type="cite" class="">
<div class="">
<div dir="ltr" class="">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 class=""><br class=""></div>
<div class="">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 class=""><br class=""></div>
<div class="">I hope this will prove satisfactory to the community :)</div>
<div class=""><br class=""></div>
<div class=""><br class=""></div>
<div class="">
<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" class="">
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" class="">
<li class="">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" class="">SE-XXXX</a></li>
<li style="margin-top:0.25em" class="">Author: <a href="https://github.com/xwu" style="background-color:transparent;color:rgb(64,120,192);text-decoration:none" target="_blank" class="">Xiaodi Wu</a></li>
<li style="margin-top:0.25em" class="">Status: <span style="font-weight:600" class="">Awaiting review</span></li>
<li style="margin-top:0.25em" class="">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'" class="">
<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" class=""></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" class="">
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" class="">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" class="">
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" class="">
<li class=""><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" class="">[Proposal] Revising access modifiers on
extensions</a></li>
<li style="margin-top:0.25em" class="">[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'" class="">
<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" class=""></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" class="">
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)" class=""><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" class="">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" class="">
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" class="">
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" class="">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" class="">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" class="">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'" class="">
<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" class=""></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" class="">
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" class="">
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)" class=""><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" class="">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" class="">
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" class="">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'" class="">
<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" class=""></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" class="">
<li class="">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" class="">internal</code>.</li>
<li style="margin-top:0.25em" class="">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" class="">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" class="">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'" class="">
<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" class=""></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" class="">
<li class="">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'" class="">
<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" class=""></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" class="">
Thanks to all discussants on the list, especially Adrian Zubarev
and Jose Cheyo Jimenez.</p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<blockquote type="cite" class="">
<div class="">
<span class="">_______________________________________________</span><span class=""><br class="">
<span class="">swift-evolution mailing list</span><br class="">
<span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="">
</span></div>
</blockquote>
</div>
</blockquote>
</div>
<br class=""></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" target="_blank" class="">swift-evolution@swift.org</a></span><br class="">
<span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="">
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
<br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
<br class=""></blockquote>
</div>
<br class=""></div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote>
</div>
</div></div></span></blockquote></div></div>_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</blockquote></div></div></div></blockquote></div><br class=""></div></div></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></body></html>