<div dir="ltr">On Fri, Mar 24, 2017 at 11:36 PM, Carl Brown1 <span dir="ltr"><<a href="mailto:Carl.Brown1@ibm.com" target="_blank">Carl.Brown1@ibm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><p><font size="2">First off, SE-0159 does not, in my opinion and the opinions of many people on this list, present a superior experience for the end user.</font></p></div></blockquote><div>That is precisely the topic of this review process.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><p><font size="2">It removes a feature that many people use and will create more confusion by rendering many online tutorials and answered questions incorrect.</font><br><br><font size="2">Furthermore, the assertion that there is a "knowable" amount of effort required to "roll back" corelibs-foundation is laughable. "Look, it compiles" is nowhere near the level of rigor required for a code base that has as much code depending on it as Foundation has. Remember that the standard for corelibs-foundation is not even "it works." The standard is: "behaves the same way on Linux that Foundation does on Darwin." If something is accessible on Linux but not on Darwin, that's a bug, and needs to get fixed. Testing, finding, and fixing the regressions the "roll back" will cause is what constitutes the bulk of the effort, and that amount of effort cannot possibly be accurately estimated.</font></p></div></blockquote><div>Agreed on the standard, but neither here nor there. First, `private` vs. `fileprivate` by definition cannot change the external API. Second, the migration from Swift 2 to 3 was an essentially equal and opposite effort, and in those portions of the code, restoring the original version is just as likely to fix regressions as migrating newer code is to introduce new ones. Third, any broadening of access from `private` to `fileprivate` that does not result in an invalid redeclaration (always flagged by the compiler) is, unless I'm mistaken, unable to change the behavior of otherwise unmodified code.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex"><div><p><br><br><font size="2">-Carl</font><br><br><br><img width="16" height="16" src="cid:1__=8FBB0A7DDF84FFF08f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Xiaodi Wu via swift-evolution ---03/24/2017 10:48:09 PM---As Chris has said in the past, the core tea"><font size="2" color="#424282">Xiaodi Wu via swift-evolution ---03/24/2017 10:48:09 PM---As Chris has said in the past, the core team is willing to endure a substantial amount of implementa</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Xiaodi Wu via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Drew Crawford <<a href="mailto:drew@sealedabstract.com" target="_blank">drew@sealedabstract.com</a>>, Jonathan Hull <<a href="mailto:jhull@gbis.com" target="_blank">jhull@gbis.com</a>></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">03/24/2017 10:48 PM</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [swift-evolution] [Review] SE-0159: Fix Private Access Levels</font><br><font size="2" color="#5F5F5F">Sent by: </font><font size="2"><a href="mailto:swift-evolution-bounces@swift.org" target="_blank">swift-evolution-bounces@swift.<wbr>org</a></font><br></p><hr width="100%" size="2" align="left" noshade style="color:rgb(128,145,165)"><span class="gmail-"><br><br><br>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.<br></span><span class="gmail-">On Fri, Mar 24, 2017 at 22:38 Drew Crawford via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank"><u><font color="#0000FF">swift-evolution@swift.org</font></u></a>> wrote:
</span><ul><br><br>
<p><span class="gmail-">On March 24, 2017 at 10:21:17 PM, Jonathan Hull (<a href="mailto:jhull@gbis.com" target="_blank"><u><font color="#0000FF">jhull@gbis.com</font></u></a>) wrote:
</span></p><ul><ul><font face="Helvetica Neue">This is exactly the problem. Both for access controls and dispatch.</font><br></ul></ul><br>How would you respond to clattner's <a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/001948.html" target="_blank"><u><font color="#0000FF">position piece</font></u></a> on this? He disputes this point directly:<br>
<ul><ul><font size="2" face="Helvetica">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...</font><br><font size="2" face="Helvetica">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.</font><p>Is it? Can you point to an instance where a member of the core team said they are aiming for “plenty of overlap”?</p></ul></ul>See above
<ul><ul><font size="2" face="Helvetica">Honestly, most of your examples could just be split into multiple files.</font></ul></ul>Specific arguments were advanced in those examples that they cannot. Can you refute them?
<ul><ul><font size="2" face="Helvetica">You are conflating effort by the swift design and implementation community with your personal effort around migration.</font></ul></ul>No, I am referencing a Swift@IBM developer who reported that
<ul><ul>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...</ul></ul>______________________________<wbr>_________________<br>swift-evolution mailing list<u><font color="#0000FF"><br></font></u><a href="mailto:swift-evolution@swift.org" target="_blank"><u><font color="#0000FF">swift-evolution@swift.org</font></u></a><u><font color="#0000FF"><br></font></u><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank"><u><font color="#0000FF">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</font></u></a><tt><font size="2">_____________________<wbr>__________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br></font></tt><tt><font size="2"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/<wbr>mailman/listinfo/swift-<wbr>evolution</a></font></tt><tt><font size="2"><br></font></tt><br><br><p></p></ul><br>
<p></p></div>
</blockquote></div><br></div></div>