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

[Xiaodi Wu]

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
>> 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...
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170324/427c5d74/attachment.html>