<div dir="ltr"><div style="font-size:13px">You're probably right. It's very likely that you have worked on more C++ codebases than I have, and I haven't been working on code for high-performance computing, so it's possible that I'm suffering from a small sample size. But if you're working on a consumer app, I do think that it's logical vtable dispatch is what you want most of the time. So in my experience, functions need to be virtual more often than not, and the C++ code I've seen would be shorter if you had to explicitly mark methods as nonvirtual rather than virtual.</div><div style="font-size:13px"><br></div><div style="font-size:13px">When I said, "programmers want virtual functions 99% of the time," I was mostly thinking of the legion of programmers who grew up learning languages where virtual methods are the only kinds of methods. Objective-C, JavaScript, Ruby, Python, Java, etc. I've worked with a few younger programmers who are thrown to the C++ sharks by management, and once they learn the difference between virtual and non-virtual methods, they tend to mark all their methods virtual as a defensive measure.</div><div style="font-size:13px"><br></div><div style="font-size:13px">You make a very good point about Swift being the second major language to take value semantics correctly. My original point though, was once most iOS developers move to Swift, I think it's possible that they'll just stick to what they're comfortable with, using classes exclusively and writing Massive View Controllers, because it's what they know, it's easy to do, and it doesn't require learning sometimes conceptually difficult new concepts. So my question is whether we want to make that more difficult for them. It seems like there are benefits and disadvantages to both. I'm just trying to raise the possibility that this may be the dominant programming paradigm in Swift for some time, as unfortunate as that may be.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Dec 21, 2015 at 10:04 AM, Dave Abrahams <span dir="ltr"><<a href="mailto:dabrahams@apple.com" target="_blank">dabrahams@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><blockquote type="cite"><span class=""><div>On Dec 20, 2015, at 3:51 PM, Michael Buckley via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></span><span class=""><div><div dir="ltr" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">+0. This seems reasonable, and a lot of the arguments are compelling. The argument put forth about library design especially so. But coming from C++, where I have to prefix nearly every method in my classes with virtual, I'm worried that we could end up with the same problem in Swift.<div><br></div><div>We don't know what the dominant paradigm in swift will be ten years from now. Inheritance has a raft of problems, but there's no guarantee that the alternatives will be better in the long run. I suspect they will be, but I also suspect we will find new and exciting problems in large codebases using more functional patterns.</div><div><br></div><div>While there's a lot of excitement in the Swift community right now about final, value types, and other language features, but I fear that when the rest of the world jumps on the Swift bandwagon, most are just going to use classes exclusively over structs and continue their OOP practices, simply because it's what they're used to.</div><div><br></div><div>Making final the default may be a great way to discourage them. But it may also get us right back to where we are in C++ today, where programmers want virtual functions 99% of the time, but have to specify each function as virtual.</div></div></div></span></blockquote><div><br></div>In my considerable experience with C++, that is not at all where we are today. Increasingly, C++ is becoming seen as a language for high-performance computing, and people working in that area learn that they don't want to pay for virtual dispatch when they don't have to. It is true that for some of them, reflexive use of OOP is hard to shake, but they do learn eventually. Note also that Swift is really the second major language to take value semantics seriously. The first was C++.</div><div><div class="h5"><div><br><blockquote type="cite"><div><div class="gmail_extra" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br><div class="gmail_quote">On Sun, Dec 20, 2015 at 2:53 PM, Charles Srstka via swift-evolution<span> </span><span dir="ltr"><<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></span><span> </span>wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>I agree with this. -1 to the proposal.</div><div><br></div><div>Charles</div><br><div><blockquote type="cite"><div><div><div>On Dec 17, 2015, at 8:00 PM, Rod Brown via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">To play devils advocate, take for example UINavigationController in UIKit on iOS.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I’ve seen multiple times in multiple projects legitimate reasons for subclassing it, despite the fact that UIKit documentation says we “should not need to subclass it”. So if we relied on Apple to “declare”, they most probably wouldn’t, and these use cases (and some really impressive apps) would become impossible.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">While I agree with all points made about “If it’s not declared subclassable, they didn’t design it that way”, I think that ties everyone’s hands too much. There is a balance between safety and functionality that must be worked out. I think this errs way too far on the side of safety.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">Rod</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite"><div>On 18 Dec 2015, at 12:51 PM, Javier Soto <<a href="mailto:javier.api@gmail.com" target="_blank">javier.api@gmail.com</a>> wrote:</div><br><div>What if one framework provider thinks “you won’t need to subclass this ever”<br><br>If the framework author didn't design and implement that class with subclassing in mind, chances are it's not necessarily safe to do so, or at least not without knowledge of the implementation. That's why I think deciding that a class can be subclassed is a decision that should be made consciously, and not just "I forgot to make it final"<br><div class="gmail_quote"><div dir="ltr">On Thu, Dec 17, 2015 at 5:41 PM Rod Brown <<a href="mailto:rodney.brown6@icloud.com" target="_blank">rodney.brown6@icloud.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div style="word-wrap:break-word"><div>My opinion is -1 on this proposal. Classes seem by design to intrinsically support subclassing.</div><div><br></div><div>What if one framework provider thinks “you won’t need to subclass this ever” but didn’t realise your use case for doing so, and didn’t add the keyword? When multiple developers come at things from different angles, the invariable situation ends with use cases each didn’t realise. Allowing subclassing by default seems to mitigate this risk at least for the most part.</div><div><br></div><div>I think this definitely comes under the banner of “this would be nice” without realising the fact you’d be shooting yourself in the foot when someone doesn’t add the keyword in other frameworks and you’re annoyed you can’t add it.</div><div><br></div><br><div><blockquote type="cite"></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>On 18 Dec 2015, at 10:46 AM, Javier Soto via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><div dir="ltr">Does it seem like there's enough interesest in this proposal? If so, what would be the next steps? Should I go ahead and create a PR on the evolution repo, describing the proposal version that Joe suggested, with classes closed for inheritance by default outside of a module?<div><br></div><div>Thanks!</div></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Dec 8, 2015 at 7:40 AM Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I understand the rationale, I just disagree with it.<br><br>IMO adding a keyword to state your intention for inheritance is not a significant obstacle to prototyping and is not artificial bookkeeping. I really don't understand how this would conflict with "consequence-free" rapid development. It is a good thing to require people to stop and think before using inheritance. Often there is a more appropriate alternative.<br><br>The assumption that it is straightforward to fix problems within a module if you later decide you made a mistake is true in some respects but not in others. It is not uncommon for apps to be monolithic rather than being well factored into separate modules, with many developers contributing and the team changing over time. While this is not ideal it is reality.<br><br>When you have the full source it is certainly *possible* to solve any problem but it is often not straightforward at all. Here is an example of a real-work scenario app developers might walk into:<br><br>1) A class is developed without subclassing in mind by one developer.<br>2) After the original developer is gone another developer adds some subclasses without stopping to think about whether the original developer designed for subclassing, thereby introducing subtle bugs into the app.<br>3) After the second developer is gone the bugs are discovered, but by this time there are nontrivial dependencies on the subclasses.<br>4) A third developer who probably has little or no context for the decisions made by previous developers is tasked with fixing the bugs.<br><br>This can be quite a knot to untangle, especially if there are problems modifying the superclass to properly support the subclasses (maybe this breaks the contract the superclass has with its original clients).<br><br>It may have been possible to avoid the whole mess if the second developer was required to add 'inheritable' and 'overrideable' keywords or similar. They are already required to revisit the source of it while adding the keywords which may lead to consideration of whether the implementation is sufficient to support inheritance in their currently intended manner.<br><br>Implementation inheritance is a blunt tool that often leads to unanticipated problems. IMO a modern language should steer developers away from it and strive to reduce the cases where it is necessary or more convenient. Making final the default would help to do this.<br><br>Supporting sealed classes and methods that can only be subclassed or overridden within the same module is not in conflict with final by default. Both are good ideas IMO and I would like to see both in Swift.<br><br>I hope the core team is willing to revisit this decision with community input. If not I will let it go, although I doubt I will ever agree with the current decision.<br><br>Matthew<br><br>Sent from my iPad<br><br>On Dec 7, 2015, at 10:30 PM, John McCall <<a href="mailto:rjmccall@apple.com" target="_blank">rjmccall@apple.com</a>> wrote:<br><br>>>> On Dec 7, 2015, at 7:18 PM, Matthew Johnson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:<br>>>> 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>>><br>>> 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>>><br>>> 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>>><br>>> 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>>><br>>> 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>><br>> 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:<br>><br>> (1) avoiding artificial bookkeeping obstacles while you’re hacking up the initial implementation of a module, but<br>><br>> (2) not letting that initial implementation make implicit source and binary compatibility promises to code outside of the module and<br>><br>> (3) providing good language tools for incrementally building those initial prototype interfaces into stronger internal abstractions.<br>><br>> 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.<br>><br>> 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.<br>><br>> John.<br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></blockquote></div><div dir="ltr">--<span> </span><br></div></div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div>Javier Soto<span> </span><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=a745LmqnDfg8U5xkzxO94fzXSZ0ZB2d7MXjmVBHs4IEjC9AdJEh2Zm1Nk-2BN4vporYg4tVaaHg09QtC-2Bc0h5S3HrI3mxzngl1iy2WOhuOLUQvdzzNAhAMMoIEAXqj6VPGJHrDWqEyZLS3a-2BppbOuNPz9a0-2Fa9EPzk3H5gVR66zsPHd35Ur2oQ5j83-2Bu-2Fxm6TGoeeXY7lKJIvFEArWZ5pgkh3hf-2BTjFYN3vBgIjbD39MU-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span> </span>_______________________________________________</div></blockquote></div></div><div style="word-wrap:break-word"><div><blockquote type="cite"><div><br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></div></blockquote></div></div></blockquote></div><div dir="ltr">--<span> </span><br></div>Javier Soto</div></blockquote></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=kND2tqgLiolwf1-2Bhgg7fFiaPS455NT9j3CATwJCX709yiEQ50E-2FgbXay44G0Ga6dCgp-2FolEGrARnyHb3-2F7EEkf3pPXI0XuAMNrJcgNAUCb3JJ2-2BpAqTHiekFOTFk-2BHsiKHzKwOgWY8p-2F-2B-2F3KCcjRnYsSPkrnasp875fTHCLE4gCU3-2FNdqxZiMajMUl-2FtFJ4H-2Fh8k3v4Jem2-2BNY3F-2Bu8s8dbQZ0bAPIbx0GtZxs9Yw7U-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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"><span> </span></span><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">_______________________________________________</span><span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><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;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div><br><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=HDu-2BON2WuckNVJ2U1s3AlFgVD2xwU1HZRuo94MM4tGuYX3g5DkI5v6eP3gbl9P7hbgyEAZcoG3enX8jjsYLH4Jq-2BTgssLNTN0fdqTTtDfHKgIsPLbWvKufK3jnBR-2Fk-2FvE4Lyo3EdJQ3vpE6Fs1d13TXGlbsIgk1-2B-2FFpuI9syB79f4Cg2an6p5NxKw-2FJIcSEfMEPmTPm4iG54owPfhJGjuH2ncTnhe9oDsgnLMxskoNE-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"></div><br>_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br><br></blockquote></div><br></div><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=JfMPa-2F7wwZPzsZ3QKA8NjtONIYX4SjbWuUxtpfsTY2iIqOd1e2cxkE1Y-2FA5Yos0Glp3kw-2BEV0ZHjgCIPyDIwIAoa0Fvt11YqkD8mMsUWGmgpbwkyZTDP-2Fqa078I8-2Bs0fwh08XZ6ZNtWCQvOZko4z7B-2Br-2BOX1XBg0QtF4URwMeRgO7IaeWuv5AJFZt1vaim8kI20Y3sLjuSxko00q0YJKUXsMjaGtjtCICgXNhLC8qeU-3D" alt="" width="1" height="1" border="0" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;min-height:1px!important;width:1px!important;border-width:0px!important;margin:0px!important;padding:0px!important"><span style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important"><span> </span>_______________________________________________</span><br style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;float:none;display:inline!important">swift-evolution mailing list</span><br style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="mailto:swift-evolution@swift.org" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">swift-evolution@swift.org</a><br style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" style="font-family:AvenirNext-Regular;font-size:14px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></div></blockquote></div><br></div></div><span class="HOEnZb"><font color="#888888"><div>
-Dave<div><br></div><br>
</div>
<br></font></span></div></blockquote></div><br></div>