[swift-evolution] [Review] SE-0159: Fix Private Access Levels
xiaodi.wu at gmail.com
Fri Mar 24 23:10:23 CDT 2017
On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
> As Chris has said in the past, the core team is willing to endure a
> substantial amount of implementation pain to present a superior experience
> for the end user. In any case, I expect that the work needed to roll back
> SE-0025 in the core libraries will likely be comparable if not less than
> the remaining ongoing work needed in the compiler to make SE-0025 work
> fully. Certainly, hundreds of hours would not be required to roll back
> corelibs-foundation alone. The exact effort required is knowable, too, as
> one can fork and migrate all uses of private to fileprivate right now and
> see how long it takes.
Update: with the caveat that corelibs-foundation tests are incomplete, it
took me about 15 mins to migrate all uses of private to fileprivate. The
tricky thing is that one has to do case-sensitive find-and-replace, and to
replace all instances of "filefileprivate" in a second round. It does not
appear that corelibs-foundation actually uses new `private` in a way that
migrating to `fileprivate` results in invalid redeclarations anywhere.
On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <
> swift-evolution at swift.org> wrote:
>> 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
>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html> 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
>> 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
>> swift-evolution mailing list
>> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution