> On Feb 13, 2017, at 6:50 AM, Adrian Zubarev via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
> Personally I’d prefer if we all together with the core team set down 
> (virtually ^^) and:
> 
> Fully re-evaluated all the access modifier mess and sketched a new future 
> oriented model on how this should have been regardless it’s breaking change 
> or not.
> Communicated the corrected model with the community.
> Only after #2 we should made a decision on how to proceed.
> 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.
> 
> 

I’m not sure any of this is really blocking ABI stability. By definition, only 
public declarations affect ABI.

Slava
> 
> 
> 
> -- 
> Adrian Zubarev
> Sent with Airmail
> 
> Am 13. Februar 2017 um 15:30:20, David Hart (da...@hartbit.com 
> <mailto:da...@hartbit.com>) schrieb:
> 
>> 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.
>> 
>> On 13 Feb 2017, at 15:25, Adrian Zubarev via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>>> I actually made a small visual of how open vs. public should work 
>>> constantly on twitter: 
>>> https://twitter.com/DevAndArtist/status/829688528216924160 
>>> <https://twitter.com/DevAndArtist/status/829688528216924160>
>>> 
>>> 
>>> 
>>> -- 
>>> Adrian Zubarev
>>> Sent with Airmail
>>> 
>>> Am 13. Februar 2017 um 15:20:10, Matthew Johnson via swift-evolution 
>>> (swift-evolution@swift.org <mailto:swift-evolution@swift.org>) schrieb:
>>> 
>>>> 
>>>> 
>>>> Sent from my iPad
>>>> 
>>>> > On Feb 13, 2017, at 1:35 AM, Rien via swift-evolution 
>>>> > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >
>>>> >
>>>> >> On 13 Feb 2017, at 06:16, Derrick Ho via swift-evolution 
>>>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >>
>>>> >> I think I we can live with the original three: public, internal, and 
>>>> >> private
>>>> >>
>>>> >> Where public is visible to all,
>>>> >> Internal is visible to all within the module, and private is visible 
>>>> >> only to the class and the same file.
>>>> >>
>>>> >> We can still fulfill the same roles that the current five fill.
>>>> >>
>>>> >> Open can become public again.
>>>> >> Public can become final public
>>>> 
>>>> 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.
>>>> 
>>>> >> Internal remains the same
>>>> >> Fileprivate assimilates into private
>>>> >>
>>>> >> Make access control simple again!
>>>> >
>>>> > Agree.
>>>> >
>>>> > To me this discussion exemplifies the “square peg in a round hole” 
>>>> > problem.
>>>> > None of these (fileprivate & open) keywords add information to a source 
>>>> > code. They do add noise however.
>>>> >
>>>> > 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”)
>>>> > This is something that would be better solved by comments imo.
>>>> 
>>>> This is not true at all. I have found the distinction useful both in 
>>>> personal projects and in a team environment.
>>>> 
>>>> >
>>>> > 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”.
>>>> > Hence it does not solve a design problem, it only leads to a cumbersome 
>>>> > interface.
>>>> 
>>>> 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.
>>>> 
>>>> >
>>>> >
>>>> > 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.
>>>> 
>>>> 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.
>>>> 
>>>> >
>>>> > Regards,
>>>> > Rien
>>>> >
>>>> > Site: http://balancingrock.nl <http://balancingrock.nl/>
>>>> > Blog: http://swiftrien.blogspot.com <http://swiftrien.blogspot.com/>
>>>> > Github: http://github.com/Balancingrock <http://github.com/Balancingrock>
>>>> > Project: http://swiftfire.nl <http://swiftfire.nl/>
>>>> >>
>>>> >
>>>> >> On Sun, Feb 12, 2017 at 9:42 PM Xiaodi Wu via swift-evolution 
>>>> >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >> On Sun, Feb 12, 2017 at 8:37 PM, Dietmar Planitzer <dplanit...@q.com 
>>>> >> <mailto:dplanit...@q.com>> wrote:
>>>> >> I know that private was scoped to files before Swift 3.
>>>> >>
>>>> >> 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.
>>>> >>
>>>> >> Anyway, I don’t see a good reason why we should end up with this, once 
>>>> >> sub-modules exist:
>>>> >>
>>>> >> open, public, module, fileprivate, private
>>>> >>
>>>> >> when we can live with this:
>>>> >>
>>>> >> open, public, module, private
>>>> >>
>>>> >> and we’re not losing anything that would be significant compared to the 
>>>> >> alternative scenario.
>>>> >>
>>>> >> Well, there's also internal: open, public, internal, (submodule, 
>>>> >> however it is named), private.
>>>> >>
>>>> >> 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.
>>>> >>
>>>> >> Regards,
>>>> >>
>>>> >> Dietmar Planitzer
>>>> >>
>>>> >>> On Feb 12, 2017, at 18:16, Xiaodi Wu <xiaodi...@gmail.com 
>>>> >>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> >>>
>>>> >>> 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.
>>>> >>>
>>>> >>>
>>>> >>> On Sun, Feb 12, 2017 at 8:08 PM, Dietmar Planitzer via swift-evolution 
>>>> >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >>> 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.
>>>> >>>
>>>> >>> 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:
>>>> >>>
>>>> >>> 1) modules can be organized into a tree with one module as the root.
>>>> >>>
>>>> >>> 2) all modules which are nodes in the same module tree form a single 
>>>> >>> resilience domain.
>>>> >>>
>>>> >>> 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.
>>>> >>>
>>>> >>> 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.
>>>> >>>
>>>> >>>
>>>> >>>
>>>> >>> Regards,
>>>> >>>
>>>> >>> Dietmar Planitzer
>>>> >>>
>>>> >>>> On Feb 12, 2017, at 16:16, Zach Waldowski via swift-evolution 
>>>> >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>>>> >>>>
>>>> >>>> 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.
>>>> >>>>
>>>> >>>> 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.
>>>> >>>>
>>>> >>>> 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:
>>>> >>>>
>>>> >>>> - 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.
>>>> >>>>
>>>> >>>> - 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.
>>>> >>>>
>>>> >>>> - 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.
>>>> >>>>
>>>> >>>> All the best,
>>>> >>>> Zachary Waldowski
>>>> >>>> z...@waldowski.me <mailto:z...@waldowski.me>
>>>> >>>>
>>>> >>>>> On Sun, Feb 12, 2017, at 04:45 PM, Xiaodi Wu via swift-evolution 
>>>> >>>>> wrote:
>>>> >>>>> On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson 
>>>> >>>>> <matt...@anandabits.com <mailto:matt...@anandabits.com>> wrote:
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution 
>>>> >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 
>>>> >>>>>> wrote:
>>>> >>>>>>
>>>> >>>>>> _Potentially_ meaningful, certainly. But what I'm hearing is that 
>>>> >>>>>> it isn't actually meaningful. Here's why:
>>>> >>>>>>
>>>> >>>>>> 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.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> 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.
>>>> >>>>>
>>>> >>>>> In what ways can that information help you?
>>>> >>>>>
>>>> >>>>>
>>>> >>>>>> 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.
>>>> >>>>>
>>>> >>>>>
>>>> >>>>> 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.
>>>> >>>>>
>>>> >>>>> 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.
>>>> >>>>>
>>>> >>>>> 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.
>>>> >>>>>
>>>> >>>>>> On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <sa...@nondot.org 
>>>> >>>>>> <mailto:sa...@nondot.org>> wrote:
>>>> >>>>>> 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.
>>>> >>>>>>
>>>> >>>>>> -Chris
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>> On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <xiaodi...@gmail.com 
>>>> >>>>>>> <mailto:xiaodi...@gmail.com>> wrote:
>>>> >>>>>>> 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.
>>>> >>>>>>>> On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution 
>>>> >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 
>>>> >>>>>>>> wrote:
>>>> >>>>>>>> Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution 
>>>> >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> a 
>>>> >>>>>>>> écrit :
>>>> >>>>>>>>
>>>> >>>>>>>> On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution 
>>>> >>>>>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 
>>>> >>>>>>>> wrote:
>>>> >>>>>>>>> Final
>>>> >>>>>>>>> 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?
>>>> >>>>>>>>
>>>> >>>>>>>> As Matthew says, this is still important.
>>>> >>>>>>>>
>>>> >>>>>>>>> Lazy
>>>> >>>>>>>>> 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?
>>>> >>>>>>>>
>>>> >>>>>>>> Sadly, there is no chance to get property behaviors into Swift 4. 
>>>> >>>>>>>> Hopefully Swift 5, but it’s impossible to say right now.
>>>> >>>>>>>>
>>>> >>>>>>>>> Fileprivate
>>>> >>>>>>>>>
>>>> >>>>>>>>> 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.
>>>> >>>>>>>>
>>>> >>>>>>>> I would still like to re-evaluate fileprivate based on 
>>>> >>>>>>>> information in the field. The theory of the SE-0025 
>>>> >>>>>>>> (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>)
>>>> >>>>>>>>  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.
>>>> >>>>>>>
>>>> >>>>>>> Infrequent use and significance are orthogonal.
>>>> >>>>>>> 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.
>>>> >>>>>>> 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.
>>>> >>>>>>>
>>>> >>>>>>>> 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.
>>>> >>>>>>>>
>>>> >>>>>>>> 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.
>>>> >>>>>>>>
>>>> >>>>>>>> -Chris
>>>> >>>>>>>>
>>>> >>>>>>>> _______________________________________________
>>>> >>>>>>>> swift-evolution mailing list
>>>> >>>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>>>>> _______________________________________________
>>>> >>>>>>> swift-evolution mailing list
>>>> >>>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>>>>
>>>> >>>>>> _______________________________________________
>>>> >>>>>> swift-evolution mailing list
>>>> >>>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>>> _______________________________________________
>>>> >>>>> swift-evolution mailing list
>>>> >>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> swift-evolution mailing list
>>>> >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> swift-evolution mailing list
>>>> >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >>>
>>>> >>
>>>> >> _______________________________________________
>>>> >> swift-evolution mailing list
>>>> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >> _______________________________________________
>>>> >> swift-evolution mailing list
>>>> >> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> >> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> >
>>>> > _______________________________________________
>>>> > swift-evolution mailing list
>>>> > swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> > https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> > <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to