<html>
<head>
<meta content="text/html; charset=utf-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 8/22/2016 2:40 PM, Adrian Zubarev
via swift-evolution wrote:<br>
</div>
<blockquote cite="mid:etPan.57bb472d.7c80f82d.8d6@devandartist.com"
type="cite">
<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>Hello dear Swift community,</p>
<p>I was updating some of my libraries where I noticed that the
new <code>open</code> access modifier made the <code>public</code>
modifier inconsistent in one way.</p>
<p>Conformances to protocols is logically the same as
inheritances on classes. </p>
</div>
</blockquote>
I don't understand why this is the case. From a practical
perspective, non-open classes by default were pushed in order to
guard against the fragile base class problem. Classes always carry
implementations with the methods you can override, while protocols
don't (in the same way). A "fragile base protocol extension
implementation" problem can be avoided today by designing your
protocols properly. Not to mention that by definition, protocols are
designed to be conformed to by other types, while not all classes
are designed to be subclassed. What problem aside from a perceived
inconsistency would allowing for non-open protocols by default
solve?<br>
<br>
<blockquote cite="mid:etPan.57bb472d.7c80f82d.8d6@devandartist.com"
type="cite">
<div class="bloop_markdown">
<ul>
<li><code>Conformances == (abstract) inheritance</code></li>
</ul>
<p>That said we should allow protocols to be <code>open/public</code>
like we now allow this distinction for classes.</p>
<ul>
<li><code>open protocol</code> from module A should mean that
I’m allowed to conform to it in module B</li>
<li><code>public protocol</code> will act as an interface in
module B</li>
</ul>
<p>Not only sounds this behavior like ‘nice to have’, it’s
inconsistency and it’s a ‘really need’ + a source breaking
change in general.</p>
</div>
</blockquote>
<blockquote cite="mid:etPan.57bb472d.7c80f82d.8d6@devandartist.com"
type="cite">
<div class="bloop_markdown">
<p>A common mistake in Swift 3.0 would be to hide protocol
members behind <code>public</code> modifier for protocols
that meant to be <code>open</code>. If a protocol member in
an open class is disallowed to be overridden by the <code>public</code>
modifier and this behavior is fixed, that will imply that
you’ll have to open the member which you intended to be not
overridable. </p>
</div>
</blockquote>
<blockquote cite="mid:etPan.57bb472d.7c80f82d.8d6@devandartist.com"
type="cite">
<div class="bloop_markdown">
<pre><code class="swift">// Before:
// In module A
public protocol Proto {
func doSomething()
}
open class Base : Proto {
// Dissallow to override - this would be a common mistake
public func doSomething() {}
}
// Used in module B - so it should be `open` after all
class Test : Proto {
func doSomething() {}
}
// After:
// In module A
open protocol Proto {
func doSomething()
}
open class Base : Proto {
// Whops we have to grant the ability to override this method now
// I made a mistake designing my protocol in Swift 3.0 :/
open func doSomething() {}
}
// In module B
class Test2 : Base {
// Uuuuuuh I can do bad things with this now if the module A was not redesigned to fix this. :)))
override func doSomething() {}
}
</code></pre>
</div>
</blockquote>
This example is a little confusing; do you mean that if protocols
are given the same open semantics as classes that there would be a
cross-module implementation problem? If so, isn't that an argument
against this?<br>
<br>
I don't see a problem with just letting the class's open/public
modifier be the last word on any implemented public protocols. If a
public protocol is applied to an open class, then that protocol
method should be allowed to be declared as either open or public,
which should be enough to satisfy the protocol conformance from the
protocol's perspective.<br>
<blockquote cite="mid:etPan.57bb472d.7c80f82d.8d6@devandartist.com"
type="cite">
<div class="bloop_markdown">
<p>Personally I don’t have any feeling of how huge the impact
might be on Swift if this behavior will be fixed. I also
cannot tell if it’s something for Swift 3.x or Swift 4.0.</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_1471887332279883776" class="bloop_sign">
<div style="font-family:helvetica,arial;font-size:13px">-- <br>
Adrian Zubarev<br>
Sent with Airmail</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
swift-evolution mailing list
<a class="moz-txt-link-abbreviated" href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>
<a class="moz-txt-link-freetext" href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a>
</pre>
</blockquote>
<br>
</body>
</html>