On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com) wrote: 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. How would you respond to clattner's position piece on this? It seems to contradict you on exactly this point, e.g. 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. A focus of Swift (like Java and Javascript) is to provide an apparently simple programming model. 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... 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.
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
