<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px; color: rgba(0,0,0,1.0); margin: 0px; line-height: auto;"><br></div> <br> <div id="bloop_sign_1490410237128793856" class="bloop_sign"></div> <br><p class="airmail_on">On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (<a href="mailto:xiaodi.wu@gmail.com">xiaodi.wu@gmail.com</a>) wrote:</p> <div><blockquote type="cite" class="clean_bq" style="font-family: Helvetica, Arial; font-size: 13px; font-style: normal; font-variant-caps: 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-size-adjust: auto; -webkit-text-stroke-width: 0px;"><span><div><span style="color: rgb(0, 0, 0); font-family: 'helvetica Neue', helvetica; font-size: 14px; font-style: normal; font-variant-caps: 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; background-color: rgb(255, 255, 255); float: none; display: inline !important;">Figuring out what's statically vs. dynamically dispatched can be very difficult with Swift. Although each rule is defensible when dissected individually, the overall scheme once `final`, `dynamic`, `@objc`, etc. are included is supremely inelegant. Far from being an example of a core value, I would say it's an example of a major weakness. I see one of the key goals of the Swift evolution process as reducing and, where possible, eliminating such designs from the language.</span></div></span></blockquote></div><p>How would you respond to clattner's&nbsp;<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html">position piece</a>&nbsp;on this? &nbsp;It seems to contradict you on exactly this point, e.g.</p><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;">Swift is another case of a hybrid model: its semantics provide predictability between obviously static (structs, enums, and global funcs) and obviously dynamic (classes, protocols, and closures) constructs. &nbsp;A focus of Swift (like Java and Javascript) is to provide an apparently simple programming model. &nbsp;However, Swift also intentionally "cheats" in its global design by mixing in a few tricks to make the dynamic parts of the language optimizable by a static compiler in many common cases...</blockquote><blockquote type="cite" style="border-top-width: 1px; border-right-width: 1px; border-bottom-width: 1px; padding-left: 5px; border-left-width: 1px !important; border-left-color: rgb(0, 64, 128) !important;">The upshot of this is that Swift isn’t squarely in either of the static or dynamic camps: it aims to provide a very predictable performance model (someone writing a bootloader or firmware can stick to using Swift structs and have a simple guarantee of no dynamic overhead or runtime dependence) while also providing an expressive and clean high level programming model - simplifying learning and the common case where programmers don’t care to count cycles.</blockquote><div></div></body></html>