<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=""><div class="">As I mentioned earlier, Erica Sadun was kind enough to add a poll about this topic to her recent blog post (<a href="http://ericasadun.com/2015/12/18/naturally-final-classes-in-swift/" class="">Naturally final classes in Swift — Erica Sadun</a>). There have been 70 respondents so far: <a href="https://www.surveymonkey.com/results/SM-FVQPXQ3J/" class="">https://www.surveymonkey.com/results/SM-FVQPXQ3J/</a>. This is obviously not a scientific sample and is not too large, but it is probably enough to give some sense of how inheritance is used by app developers as well as their opinions about final as default.</div><div class=""><br class=""></div><div class="">Here are some of the results I find especially worth noting:</div><div class=""><br class=""></div><div class="">"What percent of the classes you write are subclasses of classes <b class="">other than</b> Apple provided framework or open source library classes?”</div><div class=""><br class=""></div><div class="">66.67% indicate such subclasses only comprise 0-20% of the classes they write.</div><div class="">14.49% indicate such subclasses comprise 20-40% of the classes they write.</div><div class=""><br class=""></div><div class="">We also asked the inverse question "What percent of the classes you write are written with the intent that you will subclass them elsewhere in your app?”</div><div class=""><br class=""></div><div class="">80.00% indicate that only 0-20% of the classes they write are intended to be superclasses (subclassed elsewhere in the app).</div><div class="">7.14% indicate that 20-40% of the classes they write are intended to be superclasses (subclassed elsewhere in the app).</div><div class=""><br class=""></div><div class="">72.73% believe that final should be the default behavior.<br class=""></div><div class=""><br class=""></div><div class="">48.48% prefer an `inheritable` keyword when inheritance is intended. An additional 15.15% prefer a `nonfinal` keyword for this behavior. 64.15% prefer one of the two. Only 36.36% prefer the current state of using `final`.</div><div class=""><br class=""></div><div class="">Obviously there are slight differences between questions that are effectively asking the same thing. My guess is that this can be attributed to misunderstanding of the question in some cases. </div><div class=""><br class=""></div><div class="">The data points to a strong trend. Most classes written by respondents at the app level are not intended to be subclassed. Aligning with this trend in frequency, most of the respondents would prefer final to be the default behavior.</div><div class=""><br class=""></div><div class="">I have seen two arguments consistently emerge <i class="">against</i> making final the default. </div><div class=""><br class=""></div><div class="">The first of those arguments is coming from a vocal group of app developers (possibly a vocal minority if the survey is any indication) who want to be able to subclass Apple frameworks to work around bugs. This argument is effectively making a moot point if we are already moving towards a `sealed` default. In any case, many of the framework classes are <i class="">intended</i> to be subclassed by developers and will be marked `inheritable` or similar allowing this to continue. Furthermore, as Jordan noted it isn’t really safe to make a class `final` retroactively. Because of this it is unlikely that current framework classes will be impacted by a change to `sealed` or `final` in the near term. This is likely to be a long-term transition.</div><div class=""><br class=""></div><div class="">The other argument is that inheritance is a useful feature and requiring people to opt-in to it in their own code is going to be annoying. I find this argument somewhat surprising in a language that values safety and clarity. Safe use of inheritance requires thoughtful design. Allowing inheritance by default is <b class="">less safe</b>.<b class=""> </b>It is also <b class="">less clear</b> because the code offers no indication of whether the author designed for inheritance or not. This fact is recognized in "error of omission” arguments for making `sealed` the default. It applies no less to code within our own app or module. Problems may be easier to fix in that case, but why not make them easier to avoid in the first place?</div><div class=""><br class=""></div><div class="">The comparison with access control is not a great one IMO, especially if the survey data is indicative of wider patterns. I haven’t done any analysis, but my instinct is that internal is the correct access level <i class="">more often </i> than private. A reasonable debate could probably be held as to whether it is more problematic to access members that should be private elsewhere in the same module or to inherit from a class that wasn’t really designed for subclassing. That said, my experience and intuition says inheritance is quite a bit more problematic.</div><div class=""><br class=""></div><div class="">IMHO reducing annoyance and bookkeeping in what is arguably a significant minority of cases is a pretty weak argument for sacrificing what I strongly believe is increased clarity and safety. The argument is even weaker if a majority of developers would <i class="">prefer</i> the safety and clarity of making `final` the default. Ironically, a default of `final` is actually less annoying and less bookkeeping for developers desire clarity in their code enough to add `final` where that is actually the intent if most of the classes they write are indeed leaves of the inheritance hierarchy. </div><div class=""><br class=""></div><div class="">It is my hope that the data gathered in the survey will have some influence on this discussion. At a minimum I hope it encourages us to look deeper at this issue and gather additional data to find out whether the pattern identified by the survey holds more broadly. </div><div class=""><br class=""></div><div class="">Matthew</div><div class=""><br class=""></div><div class=""><br class=""></div><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 19, 2015, at 9:21 PM, Jordan Rose via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">On Dec 7, 2015, at 20:30 , John McCall via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class=""><blockquote type="cite" class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><blockquote type="cite" class="">Defaults of public sealed/final classes and final methods on a class by default are a tougher call. Either way you may have design issues go unnoticed until someone needs to subclass to get the behavior they want. So when you reach that point, should the system error on the side of rigid safety or dangerous flexibility?<br class=""></blockquote><br class="">This is a nice summary of the tradeoff. I strongly prefer safety myself and I believe the preference for safety fits well with the overall direction of Swift. If a library author discovers a design oversight and later decides they should have allowed for additional flexibility it is straightforward to allow for this without breaking existing client code. <br class=""><br class="">Many of the examples cited in argument against final by default have to do with working around library or framework bugs. I understand the motivation to preserve this flexibility bur don't believe bug workarounds are a good way to make language design decisions. I also believe use of subclasses and overrides in ways the library author may not have intended to is a fragile technique that is likely to eventually cause as many problems as it solves. I have been programming a long time and have never run into a case where this technique was the only way or even the best way to accomplish the task at hand.<br class=""><br class="">One additional motivation for making final the default that has not been discussed yet is the drive towards making Swift a protocol oriented language. IMO protocols should be the first tool considered when dynamic polymorphism is necessary. Inheritance should be reserved for cases where other approaches won't work (and we should seek to reduce the number of problems where that is the case). Making final the default for classes and methods would provide a subtle (or maybe not so subtle) hint in this direction.<br class=""><br class="">I know the Swift team at Apple put a lot of thought into the defaults in Swift. I agree with most of them. Enabling subclassing and overriding by default is the one case where I think a significant mistake was made.<br class=""></blockquote><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">Our current intent is that public subclassing and overriding will be locked down by default, but internal subclassing and overriding will not be. I believe that this strikes the right balance, and moreover that it is consistent with the general language approach to code evolution, which is to promote “consequence-free” rapid development by:</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> (1) avoiding artificial bookkeeping obstacles while you’re hacking up the initial implementation of a module, but</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> (2) not letting that initial implementation make implicit source and binary compatibility promises to code outside of the module and</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;"> (3) providing good language tools for incrementally building those initial prototype interfaces into stronger internal abstractions.</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">All the hard limitations in the defaults are tied to the module boundary because we assume that it’s straightforward to fix any problems within the module if/when you decided you made a mistake earlier.</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><span class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;">So, okay, a class is subclassable by default, and it wasn’t really designed for that, and now there are subclasses in the module which are causing problems. As long as nobody's changed the default (which they could have done carelessly in either case, but are much less likely to do if it’s only necessary to make an external subclass), all of those subclasses will still be within the module, and you still have free rein to correct that initial design mistake.</span><br class="" style="font-family: Monaco; font-size: 11px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"></div></div></blockquote></div><br class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">I think John summarized my position very well, so of course I'm going to come in here and add more stuff. :-)</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">In working on the design for library evolution support ("resilience"), we've come across a number of cases of "should a library author be able to change this when they release v2 of their library?" Many times, the answer is it's<span class="Apple-converted-space"> </span><i class="">possible</i><span class="Apple-converted-space"> </span>to do something in one direction, but not at all safe to go the other way. For example, you can always add public methods to a class, but you can't<span class="Apple-converted-space"> </span><i class="">remove</i> public methods because you don't know who's calling them. You can mark them deprecated, but that doesn't help with any client apps that have already been compiled and shipped.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">One of the things that came up was "can you add 'final' to a class?" And of course you can't, because you don't know who may have already subclassed it. That's very unfortunate for a library author who simply forgot to add 'final' when they were first writing the class.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">The interesting thing about this is that the "error of omission"—of failing to think about whether a class should be final—is worse than the alternative. Ignoring optimizations for a minute, a class that<span class="Apple-converted-space"> </span><i class="">starts out</i> 'final' can certainly become non-final later; it doesn't change how the class is currently used.* For a lot of library evolution questions, this is the preferred answer:<span class="Apple-converted-space"> </span><b class="">the default should be safe,</b> and the designer of the class can choose to be more aggressive later.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">This is also the guiding principle behind the behavior of 'public'. A number of people have asked for members of a public struct to implicitly be made public. But here again the "error of omission" is problematic: a helper function you add for your own use may now be depended on by client apps far and wide, just because you forgot to customize the access control. So Swift says you should explicitly consider the public interface of every type.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Why 'sealed' instead of 'final' as the default? Because inheritance is useful, and within your<span class="Apple-converted-space"> </span><i class="">own</i> code having to opt into it starts to feel like unnecessary clutter. This is a trade-off, just like defaulting to 'internal' over 'private', but it's one that keeps life easy for a single developer with a single module: their app. (And the compiler can still do useful things with non-final classes if it can see the entire class hierarchy.) Additionally, limiting inheritance to the<span class="Apple-converted-space"> </span><i class="">current</i> file (a la 'private') is also potentially useful.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">This direction separates "limiting inheritance/overrides" from "has no subclasses/overrides". The former is about defining the limits of your API; the latter is a promise that can be used for performance. I think that's a good thing.</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">Jordan</div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">* Even without optimizations a 'final' class cannot safely drop the 'final'. If a class is 'final', it may have additional 'required' initializers added in extensions.</div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=eLFMrKDT8iBxZ-2Fbnk-2BZqvSchNN-2FvYXdceA0T7VxwkAcijINEvS68TVuTlm6NrWWgMjOcNSx3pqa5mQjV6hoOPHH3iS5yIOox7RQUixg9FCUSQRcNjTvc-2BwwDIMleDAovkVBJwXoagYXBwtYMExBKDjaKU3U5tKfYFydLvUkPCkZdAqQ8jXPMUA8fZKhyDyPN2I7JN7Z5apPPy7rTnDeiwlfXom-2FlWXIMceHof6RPi2Q-3D" alt="" width="1" height="1" border="0" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; height: 1px !important; width: 1px !important; border-width: 0px !important; margin: 0px !important; padding: 0px !important;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class=""><span class="Apple-converted-space"> </span>_______________________________________________</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><span style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="mailto:swift-evolution@swift.org" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">swift-evolution@swift.org</a><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br class=""></body></html>