<div>I find the final keyword useful when I want to communicate that this class should not be subclassed.<br><br>I think the behavior should remain the same since it is useful.</div><div><br><div class="gmail_quote"><div>On Sun, Feb 12, 2017 at 5:15 PM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 12, 2017, at 3:52 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-9170636182354580656Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Sun, Feb 12, 2017 at 3:47 PM, Matthew Johnson <span class="gmail_msg"><<a href="mailto:matthew@anandabits.com" class="gmail_msg" target="_blank">matthew@anandabits.com</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 12, 2017, at 3:45 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:</div><br class="m_-9170636182354580656m_4464045931093981235Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Sun, Feb 12, 2017 at 3:24 PM, Matthew Johnson <span class="gmail_msg"><<a href="mailto:matthew@anandabits.com" class="gmail_msg" target="_blank">matthew@anandabits.com</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 12, 2017, at 2:35 PM, Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">_Potentially_ meaningful, certainly. But what I'm hearing is that it isn't actually meaningful. Here's why:</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">In what ways can that information help you?</div><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">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.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></span><div class="gmail_msg">This is really subjective and it’s not clear to me that there is substantial evidence one way or another. I know that `private` is valued and used heavily by the teams I have worked with.</div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div></div></div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">It wasn't a rhetorical question that I asked: what value do you perceive in the new `private` in terms of helping you reason through code?</div></div></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">You are right that any time it really matters it’s not hard to answer the question with a search, so it’s largely a convenience. </div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">That said, I find it quite useful to be able to mark helper methods and types within an extension `private` to make it clear that they are indeed local helper methods or types that are not accessed more broadly. This communicates an intent. As long as your extensions don’t get too large, a whole extension is usually visible on a single screen on a 27” iMac which is very useful - you don’t have to consider code that is scrolled out of sight.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">I also find it useful to be able to mark stored properties `private` and therefore *not* available to extensions. This can facilitate tighter encapsulation of state, especially when there is a handful of basis methods through which the extensions access that state.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">Maybe that’s an exception, but maybe not. I don’t think we know yet and I think this is what Chris is hoping to learn.</div><div class="gmail_msg"><div class="m_-9170636182354580656h5 gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235h5 gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">On Sun, Feb 12, 2017 at 2:14 PM, Chris Lattner <span class="gmail_msg"><<a href="mailto:sabre@nondot.org" class="gmail_msg" target="_blank">sabre@nondot.org</a>></span> wrote:<br class="gmail_msg"><div class="gmail_extra gmail_msg"><div class="gmail_quote gmail_msg"><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="gmail_msg"><div class="gmail_msg">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.<span class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089HOEnZb gmail_msg"><font color="#888888" class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg">-Chris</div></font></span></div><div class="gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089h5 gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Feb 12, 2017, at 12:02 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="gmail_msg" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">If the overwhelming use case is that developers should pick one over the other primarily because it looks nicer, then blindly click the fix-it when things stop working, then the distinction between private and fileprivate is pretty clearly a mere nuisance that doesn't carry its own weight.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div class="gmail_msg">On Sun, Feb 12, 2017 at 13:33 Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><blockquote type="cite" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Le 12 févr. 2017 à 18:24, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a>> a écrit :</div><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674m_7519834204090425122Apple-interchange-newline gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div style="word-wrap:break-word" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">On Feb 12, 2017, at 8:19 AM, David Hart via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:<br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><blockquote type="cite" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><b class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Final</b><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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?</div></div></div></div></div></blockquote><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">As Matthew says, this is still important.</div><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><blockquote type="cite" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><b class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Lazy</b></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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?</div></div></div></div></div></blockquote><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Sadly, there is no chance to get property behaviors into Swift 4. Hopefully Swift 5, but it’s impossible to say right now.</div><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><blockquote type="cite" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><b class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Fileprivate</b> </div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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.</div></div></div></div></blockquote><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">I would still like to re-evaluate fileprivate based on information in the field. The theory of the SE-0025 (<a href="https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">https://github.com/apple/swift-evolution/blob/master/proposals/0025-scoped-access-level.md</a>) was that the fileprivate keyword would be used infrequently: this means that it would uglify very little code and when it occurred, it would carry meaning and significance.</div></div></div></blockquote><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div></div></div><div style="word-wrap:break-word" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">Infrequent use and significance are orthogonal.</div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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.</div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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.</div></div></div><div style="word-wrap:break-word" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><blockquote type="cite" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div style="word-wrap:break-word" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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.</div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">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.</div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div><div class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">-Chris</div><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div>_______________________________________________<br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">swift-evolution mailing list<br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><a href="mailto:swift-evolution@swift.org" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg"></div></blockquote></div></div>_______________________________________________<br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">
swift-evolution mailing list<br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="m_-9170636182354580656m_4464045931093981235m_-4290256156081610089m_-9113574476706781674gmail_msg gmail_msg">
</blockquote></div>
</div></blockquote></div></div></div></blockquote></div><br class="gmail_msg"></div></div>
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div></div></div><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></div>
</div></blockquote></div></div></div><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></div>
</div></blockquote></div></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div></div>