On Fri, Mar 24, 2017 at 10:47 PM, Xiaodi Wu <xiaodi...@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@swift.org> wrote: > >> >> >> >> On March 24, 2017 at 10:21:17 PM, Jonathan Hull (jh...@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@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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution