> On Mar 24, 2017, at 8:10 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote:
>
> On Fri, Mar 24, 2017 at 9:55 PM, Drew Crawford <d...@sealedabstract.com
> <mailto:d...@sealedabstract.com>> wrote:
> On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi...@gmail.com
> <mailto: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
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html>
> 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.
>
>
> I agree absolutely with those aims: very predictable performance, expressive
> and clean model, simplified learning and common cases. I'm arguing that the
> giant table of dispatch rules (see:
> http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png
>
> <http://raizlabscom-wpengine.netdna-ssl.com/dev/wp-content/uploads/sites/10/2016/12/Summary-3.png>)
> does not reach that goal. At least half a dozen independent threads have
> been started on this list alone about why methods in protocol extensions can
> only be shadowed but not overridden. The goal of evolution, IMO, is precisely
> to refine the "apparent model" as much as possible, eliminating as many of
> these exposed jagged edges wherever it is reasonable to have the compiler
> make it "just work."
>
> The same argument goes here for `fileprivate` and new `private`. I don't see
> anyone who thinks that the current set of access modifiers is "clean"; and no
> one has argued that the expanded set of access modifiers "simplified learning
> and common cases." Moreover, it enables no performance wins. In fact, it does
> the *opposite* of what Chris is praising in his email. There, he says that
> Swift "provide[s] an apparently simple programming model" for dispatch but
> "cheats" under the covers to recover additional performance wins; here,
> access modifiers in Swift 3 deliberately expose a more complex model than
> before, but does not gain for the compiler any additional optimization
> opportunities from doing so.
I just wrote up a long response to Drew’s earlier email, but you said it much
more elegantly here :-)
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
