<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"><p>You might consider the topic I started about access modifier on extensions. <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160620/021418.html">LINK</a></p>

<p>Fixing this would be a breaking change, because:</p>

<ol>
<li>if you never explicitly set <code>public</code> modifier the visibility would break</li>
<li>fixing <code>implicit public modifier</code> on extensions would mean fixing the problems with protocols + extensions, because right now its not possible to use access modifier when there are protocols attached to the extension.</li>
</ol>

<p>There is no proposal yet, but there is almost no feedback on that topic as well.</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_1466614185318515968" 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 22. Juni 2016 um 18:48:45, John McCall via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</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;" class=""><div></div><div>



<title></title>


<div>
<blockquote type="cite" class="">
<div class="">On Jun 22, 2016, at 9:15 AM, Javier Soto &lt;<a href="mailto:javier.api@gmail.com" class="">javier.api@gmail.com</a>&gt;
wrote:</div>
<div class="">How would we evaluate the proposal to introduce the
"sealed" specifier for classes (open within module, final outside
of module) and default to that, in terms of source-code
compatibility?<br class="">
From my point of view it might be easier to do before Swift 3, but
if delayed until Swift 4 it wouldn't be the most time-consuming
breakage for developers.<br class=""></div>
</blockquote>
<div><br class=""></div>
<div>I believe we consider this plan of record, actually, other
than the spelling of the modifier. &nbsp;It's something we probably
ought to commit to in Swift 3, though.</div>
<div><br class=""></div>
<div>John.</div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div class="gmail_quote">
<div dir="ltr" class="">On Wed, Jun 22, 2016 at 9:09 AM Matthew
Johnson via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>&gt; 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="">
<blockquote type="cite" class="">
<div class="">On Jun 22, 2016, at 10:59 AM, John McCall
&lt;<a href="mailto:rjmccall@apple.com" target="_blank" class="">rjmccall@apple.com</a>&gt; wrote:</div>
<br class="">
<div class="">
<div style="word-wrap:break-word" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jun 22, 2016, at 8:17 AM, Matthew Johnson via
swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>&gt;
wrote:</div>
<br class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<blockquote type="cite" class="">
<div style="word-wrap:break-word" class="">
<div class="">
<ul class="">
<li class="">Rationalizing base conversion protocol names. I
personally don't have the heart to try to re-address the
"LiteralConvertible" protocol naming thing again but this would be
the last chance to do anything about getting this issue
addressed.</li>
</ul>
</div>
</div>
</blockquote>
<div class="">Given the vast amount of bike shedding that has
already happened around this topic, I don’t think there is a
solution that everyone will be happy with.&nbsp; It is also unclear
(to me at least) what solution might be acceptable to the core
team. &nbsp;</div>
</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
To be clear, I don't care about the name.&nbsp; If you want to
rename IntegerLiteralConvertible to IntegerLiteral or whatever, I
won't drag the conversation into the muck again. :) &nbsp;It's the
design of the requirements that I'm pretty opposed to
revisiting.</div>
</div>
</div>
</blockquote>
<div class=""><br class=""></div>
</div>
</div>
<div style="word-wrap:break-word" class="">
<div class="">
<div class="">This is orthogonal to the discussion that happened in
your thread, definitely no discussion of any changes to the
requirements. :)</div>
<div class=""><br class=""></div>
<div class="">We are discussing this proposal:&nbsp;<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md" target="_blank" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0041-conversion-protocol-conventions.md</a>&nbsp;and
specifically the use of the `Convertible` suffix for both the
`*LiteralConvertible` protocols and the
`Custom(Debug)StringConvertible` protocols where the conversion
runs in opposite directions.</div>
<div class=""><br class=""></div>
<div class="">The core team decision was:</div>
<div class=""><br class=""></div>
<div class="">"The feedback on the proposal was generally positive
about the idea of renaming these protocols, but the specific names
in the proposal are not well received, and there is no apparent
confluence in the community on better names.&nbsp; The core team
prefers discussion to continue -- if/when there is a strong
proposal for a better naming approach, we can reconsider renaming
these."</div>
</div>
</div>
<div style="word-wrap:break-word" class="">
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class=""><br class=""></div>
<div class="">John.</div>
<div class=""><br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap:break-word" class="">
<div class="">
<div class=""><br class=""></div>
<div class="">At the same time, it continues to bother me that
`Convertible` is used by standard library protocols with two
completely different meanings.&nbsp; This is a problem that
deserves to be solved and as it involves a breaking change Swift 3
is the right timeframe in which to do so.</div>
<div class=""><br class=""></div>
<div class="">If the core team is able to indicate an approach they
favor I would be willing to revise and resubmit the proposal.&nbsp;
But I don’t want to spend any further time speculating about what
solution might be considered acceptable.</div>
<div class=""><br class=""></div>
<div class="">Matthew</div>
</div>
<br class=""></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>
</blockquote>
</div>
<br class=""></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 dir="ltr" class="">--<br class=""></div>
<div data-smartmail="gmail_signature" class="">
<div dir="ltr" class="">Javier Soto</div>
</div>
</div>
</blockquote>
</div>
<br class="">


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