<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 10:56 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">On Fri, Feb 17, 2017 at 3:46 PM, Charlie Monroe <span dir="ltr" class=""><<a href="mailto:charlie@charliemonroe.net" target="_blank" class="">charlie@charliemonroe.net</a>></span> wrote:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><br class=""><div class=""><span class="gmail-"><blockquote type="cite" class=""><div class="">On Feb 17, 2017, at 8:21 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> wrote:</div><br class="gmail-m_-7007619946158901677Apple-interchange-newline"><div class=""><div dir="ltr" style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class="">On Fri, Feb 17, 2017 at 1:11 PM, Xiaodi Wu<span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>></span><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>wrote<wbr class="">:<br class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class=""><span class="">On Fri, Feb 17, 2017 at 12:45 PM, Vladimir.S<span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><span dir="ltr" class=""><<a href="mailto:svabox@gmail.com" target="_blank" class="">svabox@gmail.com</a>></span><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><wbr class="">wrote:<br class=""></span><div class="gmail_extra"><div class="gmail_quote"><span class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-">On 17.02.2017 20:48, Xiaodi Wu wrote:<br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">What you are really asking for is a way of flexibly designating a "unit of<br class="">code" within a module, for which the general solution is submodules. The<br class="">objection is that, instead of tackling that issue, these are suggestions to<br class="">invent ad-hoc units of code (scope + extensions only in the same file,<br class="">scope + extensions only in the same module, class + extensions only in the<br class="">same file + subclasses only in the same module), and it is possible to<br class="">invent arbitrary many of these.<br class=""></blockquote><br class=""></span>No, sorry, I don't agree with you.<br class="">Current situation forces us to generate huge source files or write each type in its own submodule/file. IMO it is very naturally to have a need to protect access to some details *even* in the same file(please find David Sweeris's answer in previous email in this thread. with current 'private' he can *guarantee* that no code touches internal props even in the same file), also many of us need a way to share some details only for extensions/subtypes in other files in the same module/submodule even just to organize code as *one* need/want and to express intention about who should "touch" this code and get help from compiler when accidentally try to use protected method/prop.<br class=""></blockquote><div class=""><br class=""></div></span><div class="">I reject the premise that it is a goal of the Swift compiler to protect you from yourself.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">I should clarify, it should certainly protect you from unintentional accidents that you make, where those are foreseeable, etc. But here we're talking about _you_ invoking functions that _you_ wrote, which is a pretty darn clear demonstration of intentionality. And so what I mean to say is that the Swift compiler, IMO, has no real business trying to protect your intentions from your other intentions.</div></div></div></div></div></blockquote><div class=""><br class=""></div></span><div class=""><div class="">With all due respect (and I do respect you as a person with quite an insight), why does Swift then (by default) check for (U)Int overflows, against nil values, etc, etc. These are all things that are quite protecting you from yourself. In a perfect world, you code your stuff in a way where you don't need these checks as you'd write code that would handle these scenarios. Oh wait, that's Objective-C...</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Overflow, nil values, etc., all go to Swift's promising of memory safety by default. They also reflect errors of omission: we unintentionally forget to handle these cases. Here, a function call is an _intentional_ act. Writing a function not meant to be called is an _intentional_ act. It is strange that you would demand the compiler to stand between two of your own intentional acts.</div></div></div></div></div></blockquote><div><br class=""></div><div>It's not that it's not meant to be called, but to be called from certain context. Coming back to a codebase after a while, you don't need to remember that method is not meant to be called out of certain context and if you name your methods well, you don't really need to go and take a look at what the method does, so you might miss this fact since you didn't go and read the docs. Xcode wouldn't even offer you this method in autocompletion if it were marked protected.</div><div><br class=""></div><div>I'm not saying that this is something the Swift community can't live without, but it's of a huge convenience for newcomers to a project for whom the IDE wouldn't offer methods that should not get called from outside of the enclosing type.</div><div><br class=""></div><div>I believe we are running to a point where the community is divided into two major camps - one part that would like to get the access control almost eliminated as they don't the see it that much useful; and second part that on the other hand would very much like to see extended access control - not by files/modules, but by the enclosing type. People are unlikely to switch these camps as their view on the subject is mostly shaped by their previous experience with working on team projects. </div><div><br class=""></div><div>IMHO, those who have previously worked with other experienced and responsible developers are probably advocates of less access control; those who have previously worked will less experienced developers are most likely pushing forward a more extended access control model.</div><div><br class=""></div><div>I've previously worked as a lead developer in a few start-up businesses where people came and went and it was unnecessary burden to point to them why they shouldn't do something that way, that they overlooked that the member should not be invoked out of the enclosing context because they didn't full read documentation for that method; when you do this with a 10th person for the 100th time, you start wondering if this is one of those things that the language should help with a little by providing means of preventing people of misusing/abusing certain parts of the API.</div><br class=""><blockquote type="cite" class=""><div class=""><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class="">In a similar sense, I believe the compiler/language should prevent you from accidently accessing members that are not designed to be accessed from out of certain scope.</div><div class=""><br class=""></div><div class="">It's not just to protect _you_ from invoking something not being meant to invoke, but others as well.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Others that are part of the collective "you" working on the project, the group of people who have permissions to touch the source code.</div><div class=""> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><div class=""><div class="">Documentation is perfect only in a perfect world. I can't count how many times I've come to a project without a single line of comment, not to mention a comment indicating whether the member is meant to be called outside of the file, or if it's marked as internal due to current limitations in access control and it's simply because you needed to split the class amongst several files logic-wise to prevent a bloated single file.</div><div class=""><br class=""></div><div class="">Documentation is not the answer.</div></div></div></div></blockquote><div class=""><br class=""></div><div class="">If documentation is not the answer, then by that line of reasoning, neither is access control. An author who can't be bothered to document that something shouldn't be used won't be bothered to determine what an appropriate access modifier would be, either. My point is that additional access modifiers don't help you express yourself any more than documentation does. Put another way, the access modifiers you advocate for are simply an alternative spelling for a comment.</div><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word" class=""><div class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="gmail-h5"><div dir="ltr" style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><div class="">You can *guarantee* that nothing in the same file touches what it shouldn't touch *by your own eyes*; `private` makes it "easier" but it is by no means necessary. Indeed I argue that reading code should be the go-to way reason about the behavior of code, and that compiler help is justified only when such a method of reasoning is unusually hard or error-prone.</div><div class=""><br class=""></div><div class="">Likewise, you can express intention by documentation. Indeed I argue that reading the documentation should be the go-to way for a reader to learn how to use unfamiliar code. Since a user will consult the documentation if he or she is wondering, "how or when should I use this method?", it is perfectly sufficient and elegant to put a sentence in the documentation that says, "actually, you should never use this method." It is self-evident why one might _want_ compiler help, but it is unclear to me why one _needs_ compiler help for this: after all, if you call an internal method that doesn't behave as intended, you can read the source code to find out exactly why--you can even change it!</div><span class=""><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Someone, who want just internal/public can use only them in own code, no problems. But many feels that they need a more detailed access levels to structure their code, they find current situation not comfortable.<br class=""></blockquote><div class=""><br class=""></div></span><div class="">As I said, there are arbitrarily many ways to structure your code. If you insist that the compiler should help you to control, perfectly, exactly what lines of code can call what other lines of code, and that the way to spell this desire is through access levels, then you will need many more access levels. My point is that, taken to its logical end, you would need infinitely many access levels. Although it would be unnecessary for the language to active prohibit certain styles of organizing code, I believe very strongly it is a non-goal of Swift to actively support, by the addition of new features, all imaginable styles of organizing code.</div><div class=""><div class="gmail-m_-7007619946158901677h5"><div class=""><br class=""></div><div class=""><br class=""></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><br class=""><br class=""><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class="">There is, objectively, an actual minimum number of access modifiers, which<br class="">is two. Those two are: visible only inside the unit of code, or visible<br class="">both inside and outside the unit of code. In Swift, those are spelled<br class="">internal and public. Everything else here is really talking about better or<br class="">more flexible ways of defining a unit of code.<br class=""><br class=""><br class="">On Fri, Feb 17, 2017 at 06:21 Vladimir.S via swift-evolution<br class=""></span><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>>> wrote:<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>On 17.02.2017 11:29, Slava Pestov via swift-evolution wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> On Feb 17, 2017, at 12:09 AM, Charlie Monroe via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>>><div class=""><div class="gmail-m_-7007619946158901677m_1994047588422378678gmail-h5"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> True, what I meant was a wider feedback - let's face it, there are many<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> more Swift developers now than 2 years ago.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> My objection is not to the documentation itself, but to the fact<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>that I'm<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> unnecessarily exposing an internal implementation detail to the rest of<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> the module. Being able to hide it from the rest IMHO leads to better<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> though-through API that is indeed meant to be exposed; whereas exposing<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> internal details leads to allowing various quick hacks instead. We know<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> these quick hacks very well from the ObjC world by accessing private<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> parts of the object via duck typing or setting values via KVO.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> At least this is my experience with which the less implementation<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>details<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> are exposed to the outer world, the better.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> I think the fundamental disagreement we’re seeing in this thread is the<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> meaning of “outer world”; to some, it means “users of your module”. To<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> others, it also means “other developers on my team who are working on<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>other<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> files in the module”.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> Personally I feel enforced encapsulation of implementation detail to the<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> latter group is less important than the former, and can be handled by<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> convention. Whereas other users of your module definitely benefit from<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> access control and being able to consume a clearly-defined interface.<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>I assume we are discussing access modifiers mainly for the former group,<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>i.e. when we are "inside" the module (even when this module is written by<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>the same one person, and especially when it is written by the group).<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>"handled by convention" - are we talking about something like declaring<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>props and methods as __privateprop , m_privateprop etc and write comments<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>to mark that they should not be used outside of some scope? Is it really<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>Swifty and acceptable for the modern language? Will this help to prevent<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>some mistakes with incorrect access? Is it better than simple and clean<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>schema for access modifiers and compiler's help? I don't understand this.<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>IMO, access modifiers is very known and handy abstraction to distinct<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>levels of access and to structure code many developers knows about and use<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>in other languages.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>At the end, if one wants to keep all internal - no problems!, you can do<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>this right now, just don't use fileprivate/private/etc.<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>Yes, I agree we need a simple and clean schema, not over-complicated, we<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>need nice&clean keywords, we need a required minimum of access modifiers,<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>not more, and I do believe currently we don't have this minimum.<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>Was already suggested, trying again(I do believe this could be a<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>compromised solution to suit needs of the main part of developers):<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>* (as currently) public/open -> outside of the module<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>* (as currently) internal -> inside module<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>* private -> inside file (instead of fileprivate)<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>* protected(or *other* keyword) -> inside file + subtype&extensions in the<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>*same module*<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>What objections could be made for this?<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>Thank you.<br class=""><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> Slava<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> On Feb 17, 2017, at 8:54 AM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>><br class=""></div></div><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> <mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:xiaodi.wu@gmail.com" target="_blank" class="">xiaodi.wu@gmail.com</a>>>> wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> That blog post starts out right away to say that it's a response to<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> community feedback. Moreover, the scenario you describe was just as<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> possible in 2014 as it is now. Finally, then as now, it's unclear why<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> you consider documentation to be "not pretty." After all, your reader<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> would need to consult the documentation before using a variable anyway.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> On Fri, Feb 17, 2017 at 01:04 Charlie Monroe via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> I'm aware of this, but that's fairly a long time ago - before Swift<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> was open source and had community feedback and before Swift was<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>used<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> widely among developers.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> To me, real-world use of the language has shown some flaws of<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> missing a protected access control, mainly having to decide between<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> having a variable internal or cramming all of the class extension<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> into one file, making it a 3KLOC mess. Either solution is not<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>pretty<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> - now I have it split among several files with an internal variable<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> commented as "Do not use, for private use of this class only."<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>> On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>> <<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:cheyo@masters3d.com" target="_blank" class=""><wbr class="">cheyo@masters3d.com</a>><br class=""></span><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><wbr class=""><mailto:<a href="mailto:cheyo@masters3d.com" target="_blank" class="">cheyo@masters3d.com</a>>>> wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>> <a href="https://developer.apple.com/swift/blog/?id=11" rel="noreferrer" target="_blank" class="">https://developer.apple.com/s<wbr class="">wift/blog/?id=11</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>> On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> How about removing fileprivate, getting Swift 2 meaning of<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>private<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> (as most people here now suggest) and add additional @protected<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> annotation for those who want a more fine-grained solution:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> @protected private - members accessable only from the<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> class/struct/enum/... and their extensions within the file<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> @protected internal - again, but you can access it even from<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> extensions and subclasses outside of the file within the entire<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> module.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> @protected public/open - the same as above, but outside the<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>modules.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> To me, this way most people here will be happy:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> - those wishing the access control gets simplified - it in fact<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> does, you don't need to use @protected, if you don't want<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>to/need to.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> - those who need a fine-grained solution, here it is.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.<wbr class="">org</a><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>>>> wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> Sent from my iPad<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.<wbr class="">org</a><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.<wbr class="">org</a><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> wrote:<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> While we’re bikeshedding, I’m going to add my two cents. Hold<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> on to your hat because this might be controversial here.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> complications that only serve to clutter the language.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> It would make a lot more sense to just have internal and<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>public<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> only. No private, no fileprivate, no lineprivate, no<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>protected.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>>> It’s all silly.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> Eh, I've used `private` to keep myself honest in terms of going<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> through some book-keeping functions instead of directly<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> accessing a property.<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> This is exactly the kind of thing I like it for and why I<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>hope we<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> might be able to keep scoped access even if it gets a new name<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> that ends up as awkward as fileprivate (allowing private to<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> revert to the Swift 2 meaning).<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> - Dave Sweeris<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> _____________________________<wbr class="">__________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>> <mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.<wbr class="">org</a><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailm<wbr class="">an/listinfo/swift-evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> _____________________________<wbr class="">__________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailm<wbr class="">an/listinfo/swift-evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> _____________________________<wbr class="">__________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailm<wbr class="">an/listinfo/swift-evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> _____________________________<wbr class="">__________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> <a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailm<wbr class="">an/listinfo/swift-evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> ______________________________<wbr class="">_________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"><wbr class=""> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a>><br class=""></span> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@<wbr class="">swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-<wbr class="">evolution@swift.org</a>>><span class="gmail-m_-7007619946158901677m_1994047588422378678gmail-"><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>>><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> ______________________________<wbr class="">_________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>> swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><wbr class=""><mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.<wbr class="">org</a>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>____________________________<wbr class="">___________________<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span>swift-evolution mailing list<br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a><span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><<wbr class="">mailto:<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.o<wbr class="">rg</a>><br class=""> <span class="gmail-m_-7007619946158901677Apple-converted-space"> </span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a><br class=""><br class=""></span></blockquote></blockquote></div></div></div><br class=""></div></div></blockquote></div><br class=""></div></div><span style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">______________________________<wbr class="">_________________</span><br style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class="">swift-evolution mailing list</span><br style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""><span style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" class=""></div></div><span style="font-family:helvetica;font-size:10px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/<wbr class="">mailman/listinfo/swift-<wbr class="">evolution</a></span></div></blockquote></div><br class=""></div></blockquote></div><br class=""></div></div>
</div></blockquote></div><br class=""></body></html>