<html><head><meta http-equiv="Content-Type" content="text/html charset=us-ascii"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 21, 2015, at 10:04 AM, Dave Abrahams 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; 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 20, 2015, at 3:51 PM, Michael Buckley 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 dir="ltr" class="" style="font-family: AvenirNext-Regular; font-size: 14px; 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;">+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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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></blockquote><div class=""><br class=""></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></blockquote></div><br class=""><div class="">In C++, you also often see polymorphic type erasure containers built on top of types that themselves don't require dynamic dispatch, like `boost::any`, `std::function`, and the like. This is something Swift makes first-class with protocols and protocol types. You don't need virtual dispatch of implementations as much if you can introduce ad-hoc virtual dispatch of interfaces at any point.</div><div class=""><br class=""></div><div class="">-Joe</div></body></html>