<html><head><style>
body {
        font-family: "Helvetica Neue", Helvetica, Arial, sans-serif;
        padding:1em;
        margin:auto;
        background:#fefefe;
}

h1, h2, h3, h4, h5, h6 {
        font-weight: bold;
}

h1 {
        color: #000000;
        font-size: 28pt;
}

h2 {
        border-bottom: 1px solid #CCCCCC;
        color: #000000;
        font-size: 24px;
}

h3 {
        font-size: 18px;
}

h4 {
        font-size: 16px;
}

h5 {
        font-size: 14px;
}

h6 {
        color: #777777;
        background-color: inherit;
        font-size: 14px;
}

hr {
        height: 0.2em;
        border: 0;
        color: #CCCCCC;
        background-color: #CCCCCC;
    display: inherit;
}

p, blockquote, ul, ol, dl, li, table, pre {
        margin: 15px 0;
}

a, a:visited {
        color: #4183C4;
        background-color: inherit;
        text-decoration: none;
}

#message {
        border-radius: 6px;
        border: 1px solid #ccc;
        display:block;
        width:100%;
        height:60px;
        margin:6px 0px;
}

button, #ws {
        font-size: 12 pt;
        padding: 4px 6px;
        border-radius: 5px;
        border: 1px solid #bbb;
        background-color: #eee;
}

code, pre, #ws, #message {
        font-family: Monaco;
        font-size: 10pt;
        border-radius: 3px;
        background-color: #F8F8F8;
        color: inherit;
}

code {
        border: 1px solid #EAEAEA;
        margin: 0 2px;
        padding: 0 5px;
}

pre {
        border: 1px solid #CCCCCC;
        overflow: auto;
        padding: 4px 8px;
}

pre > code {
        border: 0;
        margin: 0;
        padding: 0;
}

#ws { background-color: #f8f8f8; }


.bloop_markdown table {
border-collapse: collapse;  
font-family: Helvetica, arial, freesans, clean, sans-serif;  
color: rgb(51, 51, 51);  
font-size: 15px; line-height: 25px;
padding: 0; }

.bloop_markdown table tr {
border-top: 1px solid #cccccc;
background-color: white;
margin: 0;
padding: 0; }
     
.bloop_markdown table tr:nth-child(2n) {
background-color: #f8f8f8; }

.bloop_markdown table tr th {
font-weight: bold;
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }

.bloop_markdown table tr td {
border: 1px solid #cccccc;
margin: 0;
padding: 6px 13px; }

.bloop_markdown table tr th :first-child, table tr td :first-child {
margin-top: 0; }

.bloop_markdown table tr th :last-child, table tr td :last-child {
margin-bottom: 0; }

.bloop_markdown blockquote{
  border-left: 4px solid #dddddd;
  padding: 0 15px;
  color: #777777; }
  blockquote > :first-child {
    margin-top: 0; }
  blockquote > :last-child {
    margin-bottom: 0; }

code, pre, #ws, #message {
    word-break: normal;
    word-wrap: normal;
}

hr {
    display: inherit;
}

.bloop_markdown :first-child {
    -webkit-margin-before: 0;
}

code, pre, #ws, #message {
    font-family: Menlo, Consolas, Liberation Mono, Courier, monospace;
}


.send { color:#77bb77; }
.server { color:#7799bb; }
.error { color:#AA0000; }</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="bloop_markdown"><blockquote>
<p>I still have no idea why you want to make this change, other than “putting an access modifier on an extension is different from putting an access modifier on a type”. Are you trying to hide protocol conformances that would be otherwise public? </p>
</blockquote>

<p>In my proposal I cannot hide a public protocol conformance. Its not possible with normal types and it shouldn’t be possible with extensions as well. (Correct me if I’m wrong.) I really want the same access control behavior with extensions like whit classes, enums and structs. For new Swift developers such consistency would be great, because they won’t need to learn another access control behavior (second one goes to protocols). </p>

<p>As I showed in my proposal right now its possible to create three different version of public protocol default implementation:</p>

<pre><code class="swift">public protocol A {
    func foo()
}    

extension A {
    public func foo() {}
}

public extension A {
    func foo() {}
}

public extension A {
    public func foo() {}
}
</code></pre>

<p>If it was a type and I wanted <code>foo</code> to be visible I’d do this:</p>

<pre><code class="swift">public struct B {
    public func foo() {}
}
</code></pre>

<p>With the proposed content access control we’d have only one way for public protocol default implementation:</p>

<pre><code class="swift">public extension A {
    public func foo() {}
}
</code></pre>

<p>Yet it fells strange when there is protocol conformance that we’re not allowed to use access modifier anymore for our extension bag.</p>

<pre><code class="swift">// Assume `A` has no default implementation
// Extension must retain `public` because B is `public` and `A` as well
// Explicitly public which is crystal clear
public extension B : A {
     
    // foo must retain `public`
    public func foo()
     
    // custom member - implicitly internal - like on classes enums structs
    func member() {}
}
</code></pre>

<p>Some rules from the proposal:</p>

<ol>
<li><p><em>Access modifier</em> on extensions should respect the modifier of the extended type and the protocol to which it should conform.</p>

<ul>
<li><p>Public protocol:</p>

<ul>
<li><code>public type</code> + <code>public protocol</code> = <code>public extension</code></li>
<li><code>internal type</code> + <code>public protocol</code> = <code>internal extension</code></li>
<li><code>private  type</code> + <code>public protocol</code> = <code>private extension</code></li>
</ul></li>
<li><p>Internal protocol:</p>

<ul>
<li><code>public type</code> + <code>internal protocol</code> = <code>public extension</code> or <code>internal extension</code></li>
<li><code>internal type</code> + <code>internal protocol</code> = <code>internal extension</code></li>
<li><code>private type</code> + <code>internal protocol</code> = <code>private extension</code></li>
</ul></li>
<li><p>Private protocol:</p>

<ul>
<li><code>public type</code> + <code>private protocol</code> = <code>public extension</code> or <code>internal extension</code> or <code>private extension</code></li>
<li><code>internal type</code> + <code>private protocol</code> = <code>internal extension</code> or <code>private extension</code></li>
<li><code>private type</code> + <code>private protocol</code> = <code>private extension</code></li>
</ul></li>
<li><p>Multiple protocol conformance is decided analogously by using the highest access modifier from all protocols + the access level of the extended type.</p></li>
</ul></li>
</ol>

<blockquote>
<p>That has much greater consequences and a much stronger domino effect than what you’ve discussed here.</p>
</blockquote>

<p>Could you explain this a little more? Maybe I’m to blind to see what else could break this my proposal.</p>

<p></p></div><div class="bloop_original_html"><style>body{font-family:Helvetica,Arial;font-size:13px}</style><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1467056781665721856" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">--&nbsp;<br>Adrian Zubarev<br>Sent with Airmail</div></div></div><div class="bloop_markdown"><p></p></div></body></html>