<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>Personally I’d prefer if we all together with the core team set down (virtually ^^) and:</p>
<ol>
<li>Fully re-evaluated all the access modifier mess and sketched a new future oriented model on how this should have been <em>regardless</em> it’s breaking change or not.</li>
<li>Communicated the <em>corrected</em> model with the community.</li>
<li>Only after #2 we should made a decision on how to proceed.</li>
</ol>
<p>The reason I see this that way, because some part of the language seems to be a rushed mistake that everyone should now live with, just because we seek for ABI stability, we are unable to build a rocket, because our hands are tied.</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_1486996777556559104" 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 13. Februar 2017 um 15:30:20, David Hart (<a href="mailto:david@hartbit.com">david@hartbit.com</a>) schrieb:</p> <blockquote type="cite" class="clean_bq"><span><div dir="auto"><div></div><div>
<title></title>
<div>Very good graphic. But it reinforces my opinion that it's
currently more messy/complicated than I should be. It looks like an
over-designed or designed-by-comitee model. I understand that
private is useful, but not useful enough to warrant the increased
complexity. My 2 cents.</div>
<div><br>
On 13 Feb 2017, at 15:25, Adrian Zubarev via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
<br></div>
<blockquote type="cite">
<div>
<div class="bloop_markdown">
<p>I actually made a small visual of how <code>open</code> vs.
<code>public</code> should work constantly on twitter: <a href="https://twitter.com/DevAndArtist/status/829688528216924160">https://twitter.com/DevAndArtist/status/829688528216924160</a></p>
<figure><img src="https://pbs.twimg.com/media/C4OlULkW8AAQCDE.jpg" alt="open_vs_public"></figure>
</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_1486995804874431232" 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 13. Februar 2017 um 15:20:10, Matthew
Johnson via swift-evolution (<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>)
schrieb:</p>
<blockquote type="cite" class="clean_bq">
<div>
<div><span><br>
<br>
Sent from my iPad<br>
<br>
> On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
><br>
><br>
>> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution
<<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>><br>
>> I think I we can live with the original three: public,
internal, and private<br>
>><br>
>> Where public is visible to all,<br>
>> Internal is visible to all within the module, and private
is visible only to the class and the same file.<br>
>><br>
>> We can still fulfill the same roles that the current five
fill.<br>
>><br>
>> Open can become public again.<br>
>> Public can become final public<br>
<br>
This is incorrect. The way `public` behaves today is very different
than `final public`. Today it only restricts clients of a library
from subclassing the class. `final public` also prevents the
library itself from doing this not only in future versions, but
also in the current version. This is very useful behavior that is
not available if we adopt your suggestion.<br>
<br>
>> Internal remains the same<br>
>> Fileprivate assimilates into private<br>
>><br>
>> Make access control simple again!<br>
><br>
> Agree.<br>
><br>
> To me this discussion exemplifies the “square peg in a round
hole” problem.<br>
> None of these (fileprivate & open) keywords add
information to a source code. They do add noise however.<br>
><br>
> The difference between fileprivate and private is only of
importance to a group development effort. And then it is used for
internal communication within that group, never to the outside
world. In a way “private” tells other group members that they
should ask the original developer why he choose private instead of
fileprivate. (And more than often be told “just change it”)<br>
> This is something that would be better solved by comments
imo.<br>
<br>
This is not true at all. I have found the distinction useful both
in personal projects and in a team environment.<br>
<br>
><br>
> Open vs public is less obvious as there seems to be a use case
for this. However in the end it only “forces” an API user to wrap
the “public” interface so he can then use it again as “open”.<br>
> Hence it does not solve a design problem, it only leads to a
cumbersome interface.<br>
<br>
Composition is often a better approach than inheritance. Allowing a
library to expose classes publicly is very valuable. It allows them
the ability to design classes that are not intended to be
subclasses and have that intent verified by the compiler.
Supporting subclassing correctly is difficult and not always
appropriate.<br>
<br>
><br>
><br>
> Now, if we really want to add information to the source code,
then we would do away with the restriction approach entirely and
adopt an access list approach. I.e. it would be possible to specify
for each interface element which other module/file has access to
it.<br>
<br>
A long list of access specifications does not lend itself to
clarity or conciseness. While it is more specific, it is also far
more difficult to comprehend. Swift strikes a pretty good balance
of control, clarity of intent and conciseness IMO, but ultimately
this is a judgement call.<br>
<br>
><br>
> Regards,<br>
> Rien<br>
><br>
> Site: <a href="http://balancingrock.nl">http://balancingrock.nl</a><br>
> Blog: <a href="http://swiftrien.blogspot.com">http://swiftrien.blogspot.com</a><br>
> Github: <a href="http://github.com/Balancingrock">http://github.com/Balancingrock</a><br>
> Project: <a href="http://swiftfire.nl">http://swiftfire.nl</a><br>
>><br>
><br>
>> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer
<<a href="mailto:dplanitzer@q.com">dplanitzer@q.com</a>>
wrote:<br>
>> I know that private was scoped to files before Swift
3.<br>
>><br>
>> Fileprivate should obviously be removed because it is,
like I said previously, just a poor man’s package access level.
Yes, private was scoped to a file before Swift 3, but at least
there wasn’t two kinds of private for a single file. Also scoping
private to a file makes sense in Swift because it plays well with
the ability to organize the implementation of a type inside of a
file into the base type and a number of extensions. I now have to
use fileprivate in Swift 3 to pull this off while there isn’t a
requirement for a separate private access level. The fileprivate /
private distinction also needlessly gets in the way when you want
to refactor an existing type implementation into base type +
extensions, all living in the same file.<br>
>><br>
>> Anyway, I don’t see a good reason why we should end up
with this, once sub-modules exist:<br>
>><br>
>> open, public, module, fileprivate, private<br>
>><br>
>> when we can live with this:<br>
>><br>
>> open, public, module, private<br>
>><br>
>> and we’re not losing anything that would be significant
compared to the alternative scenario.<br>
>><br>
>> Well, there's also internal: open, public, internal,
(submodule, however it is named), private.<br>
>><br>
>> The question being discussed here is whether private
should have the old or new meaning. I tend to agree with others
that the new `private` doesn't add much. Modules are a different
conversation.<br>
>><br>
>> Regards,<br>
>><br>
>> Dietmar Planitzer<br>
>><br>
>>> On Feb 12, 2017, at 18:16, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>>
wrote:<br>
>>><br>
>>> What was added in Swift 3 was `private`; the old
`private` was renamed `fileprivate` with no change in behavior.
Certainly, submodules are a big topic that deserves careful
consideration. But the question being discussed here is about
rolling back the change that was implemented in Swift 3 by removing
`private` and restoring `fileprivate` to its old name.<br>
>>><br>
>>><br>
>>> On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>> Fileprivate is a feature that should not have been
added to Swift 3 because it is in the end just a needlessly limited
version of the Java package access level. Fileprivate forces me to
put all types which are related on an implementation level into the
same file while Java packages allow me to put each type
implementation into a separate file. The only thing that Java
requires is that all files which are part of the same package are
tagged with the same package id. Java’s package access level is
more powerful than fileprivate because it gives me more freedom in
how I want to organize my code while still making sure that code in
sibling and parent packages can not access symbols inside my
package which form part of the implementation details of my
package.<br>
>>><br>
>>> The first thing that needs to happen before any more
access levels are added is that a concept of sub-modules is added
to Swift along the lines of:<br>
>>><br>
>>> 1) modules can be organized into a tree with one
module as the root.<br>
>>><br>
>>> 2) all modules which are nodes in the same module tree
form a single resilience domain.<br>
>>><br>
>>> IMO, the sub-module stuff should be designed similar
if not the same way as Java packages because there are already lots
and lots of SDEs who know how Java packages work, and Java packages
are well understood, simple and straight-forward in their
mechanics.<br>
>>><br>
>>> Once sub-modules are in place, it makes sense to
revisit the access level topic. Eg in order to add a “module”
access level that represents the scope of a module. So “module”
could then do what file private can do today plus more. But we
should stop trying to add more access level to the language until
then. We also need to look much more at the bigger picture of
things instead of getting too much hung up on a single component of
a larger mechanism, when it is that larger mechanism that is
primarily interesting and relevant.<br>
>>><br>
>>><br>
>>><br>
>>> Regards,<br>
>>><br>
>>> Dietmar Planitzer<br>
>>><br>
>>>> On Feb 12, 2017, at 16:16, Zach Waldowski via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>>><br>
>>>> I vehemently agree on these points. New-private
and fileprivate "[add] more information" to a file the same way
requiring `self.` and other sorts of visual noise that Swift
normally eschews.<br>
>>>><br>
>>>> I wish for the Swift community to be introspective
enough to count both its successes and failures. SE-0025 was a
botched addition to the language. That the migrator did such a bad
job is evidence of its poor overall consideration. Adding a fix-it
strikes me as the compiler waggling its finger at me for code that
would've been perfectly fine in the past, something that it is not
at all true with the "let" fix it; accidental mutation has been
discussed a ton by the larger programming community, not-so-much
for obscure access control mechanics.<br>
>>>><br>
>>>> It's perplexing that fileprivate advocates
continue to stand on mostly theoretical benefits about new-private.
I feel nothing for the mathematical purity about the types in a
file. In practice, I can with much experience now how awful it is.
There has been no end to the confusion its introduction has
inflicted upon my team(s), people new to the language, and people
revisiting the language:<br>
>>>><br>
>>>> - My teams and coworkers are less effective at
code review from constant litigation about access control. "'Did
this need to change?' / 'No, it was just the migrator.'" has become
a disturbingly common refrain.<br>
>>>><br>
>>>> - New users are just struggling to figure out
where to put the curly braces in the first place. Having to make
them check and re-check where things go in a file, or just tell
them to use this clunky get-out-of-jail-free keyword, feels like
visiting a special kind of Pythonic hell on a language I otherwise
love and love to teach.<br>
>>>><br>
>>>> - People returning to the language feel (and often
say - just look at Twitter) Swift has a lot of syntax, and are
frustrated that the addition of a new keyword was burned on adding
something that amounts to mostly a stylistic opinion.<br>
>>>><br>
>>>> All the best,<br>
>>>> Zachary Waldowski<br>
>>>> <a href="mailto:zach@waldowski.me">zach@waldowski.me</a><br>
>>>><br>
>>>>> On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu
via swift-evolution wrote:<br>
>>>>> On Sun, Feb 12, 2017 at 3:24 PM, Matthew
Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>>
wrote:<br>
>>>>><br>
>>>>><br>
>>>>>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via
swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>>>>><br>
>>>>>> _Potentially_ meaningful, certainly. But
what I'm hearing is that it isn't actually meaningful. Here's
why:<br>
>>>>>><br>
>>>>>> If I see `fileprivate` and can understand
that to mean "gee, the author _designed_ this member to be visible
elsewhere inside the file," then it's actually meaningful. OTOH, if
I see `fileprivate` and can only deduce "gee, the author mashed
some button in his or her IDE," then it's not really telling me
anything.<br>
>>>>><br>
>>>>><br>
>>>>> You’re looking at it backward. It’s when you
see `private` and can deduce “this member is only visible inside
it’s declaring scope” that can be really helpful. *This* is what
matters.<br>
>>>>><br>
>>>>> In what ways can that information help
you?<br>
>>>>><br>
>>>>><br>
>>>>>> What you've said above, as I understand
it, is that it's not currently meaningful to see `fileprivate`
because the migrator is writing it and not the author. The improved
approach you proposed is the additional warning. In that case, the
compiler will help to ensure that when I see `fileprivate`, at
least I know it's necessary. But that's only telling me a fact
(this member is accessed at least once outside the private scope),
but it's still machine-based bookkeeping, not authorial
intent.<br>
>>>>><br>
>>>>><br>
>>>>> The important thing is that this machine-based
bookkeeping results in a proof about the code. This facilitates
reasoning about the code. You can make an argument that this proof
is not important enough to matter, but you must admit that this is
a real concrete gain in information that is immediately available
to a reader of the code (after they know that it compiles).
Personally, I find this proof to be valuable.<br>
>>>>><br>
>>>>> Comparison has been made to `let` and `var`.
In that case, whether a variable is mutated can be non-trivial to
deduce (as Swift has no uniform scheme for distinguishing mutating
from non-mutating functions; the ed/ing rule has many exceptions).
By contrast, here, I don't see any gain in information. You can
literally *see* where the (file)private member is accessed, and
when a file gets too long, even a simple text editor can do a
decent enough find.<br>
>>>>><br>
>>>>> If you're right that the real value is that
seeing `private` helps you reason about the code, then that value
must be commensurate to how often we see Swift users amending the
migrator to take advantage of it. For me, the compelling evidence
that Swift users don't find this proof to be valuable is that, by
examination of Swift 3 code, Swift users haven't bothered. If we
add a new fix-it to force them to, then of course they'll mash the
buttons, but it's pretty much declaring that they are wrong not to
care about what it seems they do not care at present.<br>
>>>>><br>
>>>>>> On Sun, Feb 12, 2017 at 2:14 PM, Chris
Lattner <<a href="mailto:sabre@nondot.org">sabre@nondot.org</a>> wrote:<br>
>>>>>> I don't fully agree: you are right that
that is the case when writing code. However, when
reading/maintaining code, the distinction is meaningful and
potentially important.<br>
>>>>>><br>
>>>>>> -Chris<br>
>>>>>><br>
>>>>>><br>
>>>>>>> On Feb 12, 2017, at 12:02 PM, Xiaodi
Wu <<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>>
wrote:<br>
>>>>>>> If the overwhelming use case is that
developers should pick one over the other primarily because it
looks nicer, then blindly click the fix-it when things stop
working, then the distinction between private and fileprivate is
pretty clearly a mere nuisance that doesn't carry its own
weight.<br>
>>>>>>>> On Sun, Feb 12, 2017 at 13:33
Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>>>>>>> Le 12 févr. 2017 à 18:24, Chris
Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
a écrit :<br>
>>>>>>>><br>
>>>>>>>> On Feb 12, 2017, at 8:19 AM, David
Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>
wrote:<br>
>>>>>>>>> Final<br>
>>>>>>>>> Can someone tell me what is
the use of 'final' now that we have 'public' default to disallowing
subclassing in importing modules? I know that 'final' has the added
constraint of disallowing subclassing in the same module, but how
useful is that? Does it hold its weight? Would we add it now if it
did not exist?<br>
>>>>>>>><br>
>>>>>>>> As Matthew says, this is still
important.<br>
>>>>>>>><br>
>>>>>>>>> Lazy<br>
>>>>>>>>> This one is clearer: if Joe
Groff's property behaviors proposal from last year is brought
forward again, lazy can be demoted from a language keyword to a
Standard Library property behavior. If Joe or anybody from the core
team sees this: do we have any luck of having this awesome feature
we discussed/designed/implemented in the Swift 4 timeframe?<br>
>>>>>>>><br>
>>>>>>>> Sadly, there is no chance to get
property behaviors into Swift 4. Hopefully Swift 5, but it’s
impossible to say right now.<br>
>>>>>>>><br>
>>>>>>>>> Fileprivate<br>
>>>>>>>>><br>
>>>>>>>>> I started the discussion early
during the Swift 4 timeframe that I regret the change in Swift 3
which introduced a scoped private keyword. For me, it's not worth
the increase in complexity in access modifiers. I was very happy
with the file-scope of Swift pre-3. When discussing that, Chris
Latner mentioned we'd have to wait for Phase 2 to re-discuss it and
also show proof that people mostly used 'fileprivate' and not the
new 'private' modifier as proof if we want the proposal to have any
weight. Does anybody have a good idea for compiling stats from
GitHub on this subject? First of all, I've always found the GitHub
Search quite bad and don't know how much it can be trusted.
Secondly, because 'private' in Swift 2 and 3 have different
meanings, a simple textual search might get us wrong results if we
don't find a way to filter on Swift 3 code.<br>
>>>>>>>><br>
>>>>>>>> I would still like to re-evaluate
fileprivate based on information in the field. The theory of the
SE-0025 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md">https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md</a>)
was that the fileprivate keyword would be used infrequently: this
means that it would uglify very little code and when it occurred,
it would carry meaning and significance.<br>
>>>>>>><br>
>>>>>>> Infrequent use and significance are
orthogonal.<br>
>>>>>>> I still think developers would declare
all ivars private (this is less ugly and shorter), and then will
happily convert them to fileprivate each time the compiler will
tell them they are not accessible somewhere else in the file.<br>
>>>>>>> As the code that try to access that
ivar is in the same file anyway, it has full knowledge of the
implementation details and there is no good reason it shouldn’t be
able to access the ivar when needed.<br>
>>>>>>><br>
>>>>>>>> We have a problem with evaluating
that theory though: the Swift 2->3 migrator mechanically changed
all instances of private into fileprivate. This uglified a ton of
code unnecessarily and (even worse) lead programmers to think they
should use fileprivate everywhere. Because of this, it is hard to
look at a random Swift 3 codebase and determine whether SE-0025 is
working out as intended.<br>
>>>>>>>><br>
>>>>>>>> The best way out of this that I
can think of is to add a *warning* to the Swift 3.1 or 4 compiler
which detects uses of fileprivate that can be tightened to
“private” and provide a fixit to do the change. This would be
similar to how we suggest changing ‘var’ into ‘let’ where possible.
Over time, this would have the effect of getting us back to the
world we intended in SE-0025.<br>
>>>>>>>><br>
>>>>>>>> -Chris<br>
>>>>>>>><br>
>>>>>>>>
_______________________________________________<br>
>>>>>>>> swift-evolution mailing list<br>
>>>>>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>>>>>>
_______________________________________________<br>
>>>>>>> swift-evolution mailing list<br>
>>>>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>>>>><br>
>>>>>>
_______________________________________________<br>
>>>>>> swift-evolution mailing list<br>
>>>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>>>>
_______________________________________________<br>
>>>>> swift-evolution mailing list<br>
>>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>>><br>
>>>>
_______________________________________________<br>
>>>> swift-evolution mailing list<br>
>>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>><br>
>>> _______________________________________________<br>
>>> swift-evolution mailing list<br>
>>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>>><br>
>><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
>> _______________________________________________<br>
>> swift-evolution mailing list<br>
>> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
><br>
> _______________________________________________<br>
> swift-evolution mailing list<br>
> <a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
<br>
_______________________________________________<br>
swift-evolution mailing list<br>
<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br>
</span></div>
</div>
</blockquote>
</div>
<div class="bloop_markdown"></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>
</div></div></span></blockquote></div><div class="bloop_markdown"><p></p></div></body></html>