<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>To summarize everything, I think whenever we get submodules in Swift having a consistent <code>public</code> vs. <code>open</code> behavior would have a great impact when some of us will work on huge (team) projects.</p>
<p>I do not actively support the idea of <code>@closed</code>. I see its benefits, but first I need to get my head around it’s complete behavior (on all different types, on their members). That said I’ll be more quite on that problem. :)</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_1487178827313672192" 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 15. Februar 2017 um 18:09:52, 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>As I already said:</p>
<ol>
<li>To make that feature happen, we need the protocol to be public
(regardless if you can conform to it or not).</li>
<li>Today you can conform to every protocol because in reality they
are <code>open</code> today.</li>
<li>If we remove the property requirement from the protocol the
client can conform it to any type and break my API by calling the
subscript with a wrong type: <code>document["something",
NSObject()]</code> (assuming <code>extension NSObject :
SubscriptParameterType</code>).</li>
<li>That forces me to create a requirement for the protocol which
solves the issue in my cases, however there might exist other
issues, which could be far more complicated than mine is.</li>
<li>That also implies I have make the enum public.</li>
<li>Which follows by the fact that I’m creating unnecessary copy
operations to wrap every instance that conforms to my protocol into
an enum case. From internal API perspective I also have to unwrap
the enum case.</li>
</ol>
<p>Instead if we had consistent <code>public</code> vs.
<code>open</code> behavior, I could make the protocol public
(but-not-open), remove the requirement from it completely, remove
the enum completely and simply cast to <code>Int</code> or
<code>String</code> because as the author of the library I would
know that the client won’t be able to conform to my protocol.</p>
<p>Importing my library will show the client only this:</p>
<pre><code class="swift">extension Int : SubscriptParameterType {}
extension String : SubscriptParameterType {}
</code></pre></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_1487177471251537920" 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 15. Februar 2017 um 17:50:41, Rien
(<a href="mailto:rien@balancingrock.nl">rien@balancingrock.nl</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div>
<div><span><br>
> On 15 Feb 2017, at 17:22, Adrian Zubarev via swift-evolution
<swift-evolution@swift.org> wrote:<br>
><br>
> A short example where I personally wanted a
public-but-not-open protocol:<br>
><br>
> public protocol SubscriptParameterType {<br>
><br>
> // This property was needed to prevent the client from
breaking<br>
> // the library by conforming to the protocol, but I'd like
to<br>
> // keep it invisible for the client, or even better prevent
the<br>
> // client from conforming to the protocol.<br>
> var parameter: Document.SubscriptParameter { get }<br>
> }<br>
><br>
> extension Document {<br>
><br>
> public enum SubscriptParameter {<br>
><br>
> case string(String)<br>
> case integer(Int)<br>
> }<br>
> }<br>
><br>
> extension String : SubscriptParameterType {<br>
><br>
> public var parameter: Document.SubscriptParameter {<br>
><br>
> return .string(self)<br>
> }<br>
> }<br>
><br>
> extension Int : SubscriptParameterType {<br>
><br>
> public var parameter: Document.SubscriptParameter {<br>
><br>
> return .integer(self)<br>
> }<br>
> }<br>
><br>
> // Somewhere inside the `Document` type<br>
> public subscript(firstKey: String, parameters:
SubscriptParameterType...) -> Value? { … }<br>
><br>
> That implementation enables more safe queries of my Document
type like document["key1", intIndexInstance, stringKeyInstance, 10,
"key"] rather than
document["key1/\(intIndexInstance)/\(stringKeyInstance)/10/key”]<br>
<br>
I see how that makes queries better.<br>
However what I do not see is how making the protocol “open” would
make this less safe.<br>
(I do not see a reason to make it open either, but that is not the
question)<br>
<br>
It may be obvious to everyone else, but I don’t see it. Am I
suffering from a brain freeze?.<br>
<br>
Regards,<br>
Rien.<br>
<br>
<br>
> .<br>
><br>
<br>
><br>
><br>
><br>
> --<br>
> Adrian Zubarev<br>
> Sent with Airmail<br>
><br>
> Am 15. Februar 2017 um 17:03:32, Matthew Johnson via
swift-evolution (swift-evolution@swift.org) schrieb:<br>
><br>
>><br>
>>> On Feb 15, 2017, at 9:59 AM, Rien
<Rien@Balancingrock.nl> wrote:<br>
>>><br>
>>>><br>
>>>> On 15 Feb 2017, at 16:45, Matthew Johnson
<matthew@anandabits.com> wrote:<br>
>>>><br>
>>>>><br>
>>>>> On Feb 15, 2017, at 9:35 AM, Rien
<Rien@Balancingrock.nl> wrote:<br>
>>>>><br>
>>>>><br>
>>>>>> On 15 Feb 2017, at 16:11, Matthew Johnson
via swift-evolution <swift-evolution@swift.org> wrote:<br>
>>>>>><br>
>>>>>><br>
>>>>>>> On Feb 15, 2017, at 5:59 AM, Jeremy
Pereira via swift-evolution <swift-evolution@swift.org>
wrote:<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>> On 15 Feb 2017, at 11:11, Brent
Royal-Gordon via swift-evolution <swift-evolution@swift.org>
wrote:<br>
>>>>>>>><br>
>>>>>>>><br>
>>>>>>>> Our philosophy in general,
however, is to default to the behavior which preserves the most
flexibility for the library designer.<br>
>>>>>>><br>
>>>>>>> Actually, I thought the philosophy was
to preserver type safety. When did that change?<br>
>>>>>>><br>
>>>>>>> Also, when was the library designer
prioritised ahead of the application developer?<br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>> Both open and non-open classes are
common, but we chose to give non-open classes the `public` keyword
because that's the flexibility-preserving option.<br>
>>>>>>><br>
>>>>>>> No it isn’t, it’s the flexibility
restricting option. The consumer of an open class can subclass it.
The consumer of a public class cannot subclass it. How is the
second more flexible than the first?<br>
>>>>>><br>
>>>>>> It reduces complexity for the library
author by allowing them to opt-out of the complexity involved in
supporting unknown, user-defined subclasses. It is important to
allow libraries to have this flexibility. They are free to declare
a class `open` if they want to allow subclassing. It’s even
possibly for a library to declare all classes `open` if it wishes
to do so. But *requiring* that would reduce the design space
libraries are allowed to explore and / or introduce fragility by
moving the subclass restriction to a comment.<br>
>>>>>><br>
>>>>><br>
>>>>> Why would a library author want to prohibit
subclasses?<br>
>>>>> A library user can always wrap the class and
subclass the wrapper.<br>
>>>><br>
>>>> This is composition, not inheritance. The most
important difference is that a wrapper cannot override methods, it
can only wrap and / or forward them. This means that when the
superclass calls a method on `self` that method *always* invokes
its version of that method rather than a subclass override. This is
a very important difference.<br>
>>>><br>
>>><br>
>>> Agreed, however that does not answer the question why
would a library developer want to disallow subclassing?<br>
>>> I do not see a use case for that. I.e. a feature that
cannot be implemented without it. (without “open”)<br>
>><br>
>> The feature it enables is more robust libraries and the
ability for library authors to better reason about their code. You
may not find this benefit enough to be worth a language feature,
but many of us do.<br>
>><br>
>>><br>
>>> Rien.<br>
>>><br>
>>>>><br>
>>>>> There are cases where subclassing does not
make sense. And thus preventing subclasses adds information for
those users that don’t RTFM. But that imo is not worth the impact
extra complexity places on all other users.<br>
>>>>><br>
>>>>> Rien.<br>
>>>>><br>
>>>>>>><br>
>>>>>>><br>
>>>>>>>
_______________________________________________<br>
>>>>>>> swift-evolution mailing list<br>
>>>>>>> swift-evolution@swift.org<br>
>>>>>>>
https://lists.swift.org/mailman/listinfo/swift-evolution<br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>> swift-evolution mailing list<br>
>>>>>> swift-evolution@swift.org<br>
>>>>>>
https://lists.swift.org/mailman/listinfo/swift-evolution<br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> swift-evolution@swift.org<br>
>>
https://lists.swift.org/mailman/listinfo/swift-evolution<br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> swift-evolution@swift.org<br>
> https://lists.swift.org/mailman/listinfo/swift-evolution<br>
<br></span></div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></div>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>