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

Drew Crawford drew at sealedabstract.com
Fri Mar 24 22:38:22 CDT 2017

On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jhull at gbis.com) wrote:

This is exactly the problem. Both for access controls and dispatch.

How would you respond to clattner's position piece on this?  He disputes this point directly:

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.
Is it?  Can you point to an instance where a member of the core team said they are aiming for “plenty of overlap”?

See above

Honestly, most of your examples could just be split into multiple files.
Specific arguments were advanced in those examples that they cannot.  Can you refute them?

You are conflating effort by the swift design and implementation community with your personal effort around migration.
No, I am referencing a Swift at IBM developer who reported that 

the open-source version of Foundation still has a long way to go to get the level of quality of the existing Objective-C frameworks, and we already have enough work to do without having to go make a bunch of arbitrary changes and risk a bunch of regressions because someone doesn't like a keyword... Accepting this proposal would waste hundreds of person-hours of work...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/b7816b3d/attachment.html>

More information about the swift-evolution mailing list