<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div><br>On Jun 20, 2016, at 10:35 AM, Adrian Zubarev via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div><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><div class="bloop_markdown"><p>Everyone does feel comfortable with <code>implicit public extensions</code>?</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_1466411689134916096" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">--&nbsp;<br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 19. Juni 2016 um 09:18:35, Adrian Zubarev (<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div></div><div>




<title></title>



<div class="bloop_markdown">
<p>One problem I found with the mentioned suggestion of mine is
this:</p>
<pre><code class="swift">public protocol A {}

public class B {}

// 'public' modifier cannot be used with   
// extensions that declare protocol conformances
public extension B: A {}
</code></pre>
<ul>
<li>Why is that like this?</li>
<li>Can this be fixed?</li>
<li>Implicit public <code>extension</code> feels odd and is
inconsistent if you ask me.</li></ul></div></div></div></span></blockquote></div></div></blockquote><div><br></div><div>Doug explained some of the compiler internals as related to protocol conformance on protocols (particularly why private conformance is at this point unlikely). Reading it might give more perspective to the current state. I'm sorry I cannot point to his post exactly, but it did happen in the last 3 weeks.</div><div><br></div><blockquote type="cite"><div><div class="bloop_original_html"><blockquote type="cite" class="clean_bq"><span><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div><div class="bloop_markdown"><ul>
</ul>
<p>Any statement to the pitched suggestion?</p>
</div>
<div class="bloop_original_html">

<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_1466320413381489920" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
--&nbsp;<br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
<br>
<p class="airmail_on">Am 17. Juni 2016 um 11:28:18, Adrian Zubarev
(<a href="mailto:adrian.zubarev@devandartist.com">adrian.zubarev@devandartist.com</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">
<div>
<div class="bloop_markdown">
<p><span>I’ve spotted some inconsistency on access control modifier
I’d like to discuss in this thread (the behavior is not
groundbreaking but inconsistent from readers and developers view
perspective).</span></p>
<ul>
<li>
<p><span>Why are extensions not marked as <code>public</code> in
public apis when the module is imported?</span></p>
<blockquote>
<p><span>Any type members added in an extension have the same
default access level as type members declared in the original type
being extended. If you extend a public or internal type, any new
type members you add will have a default access level of internal.
If you extend a private type, any new type members you add will
have a default access level of private.</span></p>
<p><span>Alternatively, you can mark an extension with an explicit
access level modifier (for example, private extension) to set a new
default access level for all members defined within the extension.
This new default can still be overridden within the extension for
individual type members.</span></p>
<p><span>Source: Apple Inc. The Swift Programming Language (Swift
2.2).</span></p>
</blockquote>
<ul>
<li><span>This does not tell us how the access control modifier
works on extensions. Here are three examples:</span></li>
</ul>
<pre><span><code class="swift">public struct A {}
       
/* implicitly internal */ extension A {}
       
// This extension won't be exported
</code></span></pre>
<ul>
<li><span>as soon as at least one member modifier of an extension
is <code>public</code> (if the extended type allows that and is
also <code>public</code>), the extension itself becomes implicitly
<code>public</code>:</span></li>
</ul>
<pre><span><code class="swift">public struct B {}
       
/* implicitly public */ extension B {
           
    public func foo() {}       
           
    /* implicitly internal */ func boo() {}
}
       
// This extension will be exported as
       
extension B {
           
    public func foo()
}
</code></span></pre>
<p><span>This is inconsistent to other types, because you can not
leave out the modifier for instance on classes, then add a public
member and assume that your class is implicitly
<code>public</code>! The compiler knows that and provides a correct
warning that the mentioned class is
<code>internal</code>.</span></p>
<pre><span><code class="swift">public struct C {}
       
public extension C {
           
    public func foo() {}       
           
    /* implicitly internal */ func boo() {}
}
       
// This extension will be exported as
       
/* public is missing here */ extension C {
           
    public func foo()
}
</code></span></pre>
<p><span>Extensions seem to behave differently and its behaviors is
inconsistent and not documented.</span></p>
</li>
<li>
<p><span>protocols has explicit <code>public</code> modifier on its
members when the module is imported. However, <code>'public'
modifier cannot be used in protocols</code> is how the compiler
treat modifiers in protocols on declaration.</span></p>
<pre><span><code class="swift">public protocol D {
           
    func doSomething()
}
</code></span></pre>
<p><span>Protocol <code>D</code> will be exported as:</span></p>
<pre><span><code class="swift">public protocol D {
           
    public func doSomething()
}
</code></span></pre></li>
</ul>
<p><span>Here is my suggestion:</span></p>
<ul>
<li>
<p><span>Fix the behavior for extensions and document it
correctly:</span></p>
<pre><span><code class="swift">public struct B {}
       
/* implicitly public */ extension B {
           
    public func foo() {}       
           
    /* implicitly internal */ func boo() {}
}
</code></span></pre>
<ul>
<li><span>Such an <code>extension</code> should not be implicitly
public and behave like other types and stay implicitly
<code>internal</code>.</span></li>
<li><span>The compiler should provide a warning for the
<code>foo()</code> function: <code>Declaring a public function for
an internal type</code></span></li>
<li><span>Extensions should have explicit <code>public</code>
modifier like other types if the <code>extension</code> was marked
as <code>public</code> and was imported into an other
project/module.</span></li>
<li><span><strong>This inconsistent behavior is source breaking and
I’d suggest this change to happen in Swift 3!</strong></span></li>
</ul>
</li>
<li>
<p><span>Remove <code>public</code> modifier from imported
protocols OR document this behavior correctly!</span></p>
</li>
</ul>
</div>
<div class="bloop_original_html">
<div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;">
<span><br></span></div>
<span><br></span>
<div id="bloop_sign_1466150541337204992" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">
<span>--&nbsp;<br>
Adrian Zubarev<br>
Sent with Airmail</span></div>
</div>
</div>
<div class="bloop_markdown"></div>
</div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></div>


</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>