<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>I’d support the breaking change here to allow the language to evolve properly instead of introducing halve baked opt-ins and workarounds for issues that totally deserve a fix. The first thought that I had when reading the proposal the first time was, that <code>extend</code> does not add any benefit to the language and should be implicit by default, where on the other hand <code>default</code> solves a real problem we’re having today. David was quicker and pitched the ideal solution by making <code>default</code> necessary in Swift 4 which is a breaking change but it solves the issue nicely.</p>
<p>That said, personally I would not support the opt-in version.</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_1497640056210490880" class="bloop_sign"><div style="font-family:helvetica,arial;font-size:13px">-- <br>Adrian Zubarev<br>Sent with Airmail</div></div> <br><p class="airmail_on">Am 16. Juni 2017 um 21:06:58, Paul Cantrell 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jun 16, 2017, at 1:14 PM, Erica Sadun 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<blockquote type="cite" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class="">On Jun 16, 2017, at 8:44 AM, David Hart <<a href="mailto:davidhart@fastmail.com" class="">davidhart@fastmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Okay, I undertand. I’m just worried that the proposal is a
net negative if the keywords stay optional. I’ll mention it in more
detail once we get to the review period.
<div class=""><br class=""></div>
<div class="">Thanks for the work on the proposal!!<br class=""></div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class=""></div>
</div>
</div>
</div>
</div>
</div>
<div class="">I believe a breaking change has little chance of
being accepted at this point in the language lifecycle. Adding
opt-in compiler auditing to increase safety is, IMO, a net
positive. It's a deliberate trade-off. We have included other
designs to allow the core team to choose an alternative they feel
is best for the philosophy and direction of Swift. This doesn't
close the door to future language releases enhancing the concept,
phasing out the second keyword, or introducing keywords for
additional safety auditing.</div>
<div class=""><br class=""></div>
<div class="">I find it a dangerous philosophy to insist that any
new proposal be ideologically pure. Imperfect proposals can still
improve the language within the realities of the timelines, user
base, and code base of the Swift community.</div>
</div>
</div>
</blockquote>
<div class="">
<blockquote type="cite" class=""><br class=""></blockquote>
</div>
<div class="">
<blockquote type="cite" class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">-- E</div>
</div>
</blockquote>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class=""></div>
</div>
</div>
</div>
<div class="">I share David’s concern. I also tend to think Erica’s
correct about breaking changes. If the core team says “go ahead and
break it,” then I’m all for it, but that seems unlikely.</div>
<div class=""><br class=""></div>
<div class="">FWIW, if we’re sticking with the two-keyword
approach, the language could emit warnings for _any_ extension
members that aren’t marked with either `extend` or `default`.</div>
<div class=""><br class=""></div>
<div class="">P</div>
<div class=""><br class=""></div>
<br class="">
<blockquote type="cite" class="">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">
<div class=""><br class=""></div>
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">
<div class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 16 Jun 2017, at 16:33, Erica Sadun <<a href="mailto:erica@ericasadun.com" class="">erica@ericasadun.com</a>>
wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">
<div class="">As we say in our introduction, we're pitching the
most conservative approach. </div>
<div class=""><br class=""></div>
<blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class="">
<div class="">The proposal was designed for minimal language
impact. It chooses a conservative approach that can be phased in
first over time and language release over more succinct
alternatives that would impact existing code bases.</div>
</blockquote>
<div class=""><br class=""></div>
<div class="">We discuss the one keyword version (which most of us
are a fan of) in the alternatives. The core team has to decide how
much they're willing to allow existing code to warn and/or break,
which is the consequence of the one keyword solution.</div>
<div class=""><br class=""></div>
<div class="">-- E</div>
<div class=""><br class=""></div>
<div class="">
<blockquote type="cite" class="">
<div class="">On Jun 16, 2017, at 7:44 AM, David Hart <<a href="mailto:davidhart@fastmail.com" class="">davidhart@fastmail.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div class="">
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Erica, any thoughts on only having default and making it
an error in a future version of Swift like was discussed on this
thread? The idea seems to have a few supporters.
<div class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On 16 Jun 2017, at 15:33, Erica Sadun 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class="">
<div class="">
<blockquote type="cite" class="">
<div class="">On Jun 14, 2017, at 11:46 PM, Dave Abrahams 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 class=""><br class="">
on Wed Jun 14 2017, Chris Lattner <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
<blockquote type="cite" class="">
<blockquote type="cite" class="">On Jun 14, 2017, at 10:11 AM,
Erica Sadun via swift-evolution<br class="">
<<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
<br class="">
Some pals and I have been kicking an idea around about
introducing<br class="">
better ways to support the compiler in protocol extensions. We
want<br class=""></blockquote>
<br class="">
<blockquote type="cite" class="">to eliminate some hard-to-detect
bugs. We've been brainstorming on<br class="">
how to do this without affecting backward compatibility
and<br class="">
introducing a minimal impact on keywords.<br class="">
<br class="">
We'd love to know what you think of our idea, which is to
introduce<br class="">
"role" keywords. Roles allow the compiler to automatically check
the<br class="">
intended use of a extension member definition against its
protocol<br class="">
declarations, and emit errors, warnings, and fixits as needed.
We<br class="">
think it's a pretty straightforward approach that, if
adopted,<br class="">
eliminates an entire category of bugs.<br class="">
<br class="">
The draft proposal is here:<br class="">
<a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" class="">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a><br class="">
<<a href="https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4" class="">https://gist.github.com/erica/14283fe18254489c1498a7069b7760c4</a>><br class="">
<br class="">
Thanks in advance for your thoughtful feedback,<br class=""></blockquote>
<br class="">
+1 on the idea of this. <br class=""></blockquote>
<br class="">
ditto. IMO it also makes the protocol extension much more
expressive<br class="">
and easy to read.<br class="">
<br class="">
--<br class="">
-Dave<br class=""></div>
</div>
</blockquote>
</div>
<br class="">
<div class=""><br class=""></div>
<div class="">Pull request: <a href="https://github.com/apple/swift-evolution/pull/724" class="">https://github.com/apple/swift-evolution/pull/724</a></div>
<div class=""><br class=""></div>
<div class="">-- E</div>
<div class=""><br class=""></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="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</blockquote>
</div>
<br class=""></div>
</div>
</div>
</div>
</blockquote>
</div>
<br class=""></div>
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div>
</blockquote>
</div>
<br class=""></div>
_______________________________________________<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>