[swift-evolution] [Review] SE-0159: Fix Private Access Levels

[Jonathan Hull]

> On Mar 24, 2017, at 8:10 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> 
> On Fri, Mar 24, 2017 at 9:55 PM, Drew Crawford <drew at sealedabstract.com <mailto:drew at sealedabstract.com>> wrote:
> On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (xiaodi.wu at gmail.com <mailto:xiaodi.wu at 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 :-)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/63c7a544/attachment.html>