> 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
