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

Xiaodi Wu xiaodi.wu at gmail.com
Fri Mar 24 22:10:43 CDT 2017

On Fri, Mar 24, 2017 at 9:55 PM, Drew Crawford <drew at sealedabstract.com>

> On March 24, 2017 at 9:50:01 PM, Xiaodi Wu (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:
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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/f070cf10/attachment.html>

More information about the swift-evolution mailing list