<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><span></span></div><div><div></div><div><blockquote type="cite"><div id="AppleMailSignature"><font color="#000000"><span style="background-color: rgba(255, 255, 255, 0);">Using extensions for "code organization" is another word for writing spaghetti code.</span></font></div></blockquote><br></div><div>Using extensions for code organization is a practice established and recommended by the Core Team from the very beginning (such as this blog post from August 2014: <a href="https://developer.apple.com/swift/blog/?id=8">https://developer.apple.com/swift/blog/?id=8</a>). </div><div><br></div><div>Additionally, here's Chris Lattner himself in regards to extensions:</div><div><br></div><div><blockquote type="cite"><span style="background-color: rgba(255, 255, 255, 0);">This design is true to the existing design of Swift: we want to encourage the implementation of types to be freely broken into extensions. This alignment with extension oriented programming was the one important virtue of the Swift 1/2 access control design that Swift 3 lost.</span></blockquote></div><div><br></div><div>So while you personally may not use extensions, calling the use of them "spaghetti code" is rather misguided IMO.</div><div><br></div><div>Regardless, as a final plea to the Core Team regarding this proposal: unsurprisingly, the people who are on this mailing list represent a specific subset of Swift users, and not the Swift user base as a whole. The arguments against this proposal I truly believe are not relevant to the "average" Swift user. </div><div><br></div><div>A newcomer to Swift would probably begin by putting all logic for a class in one class declaration, and using "private" for private members (as is expected). However, once they find out about the Swift practice of using extensions to separate out logic, they will hit a roadblock as they will be unable to use private members as is, and rather than understand why, they very well may simply choose to never adopt an extension-based workflow, which is unfortunate. However, if this proposal was accepted, they could easily go from one class declaration to one with extensions, without even having to learn about fileprivate.</div><div><br></div><div>I truly believe this lessening of restrictions over private member in extensions (which is used by practically all levels of Swift programmers) is more important to the language than the ability to truly restrict types to just the original class scope (which I believe is primarily used by more "advanced" users). Experienced users know what they're doing, and can deal with shortcomings (such as prefixing truly private members with underscores). Newcomers/"average" users don't as much, and this friction is a much bigger deal for them. Also, while some have mentioned that this adds complexity to the access control system because types are now a factor, to that I say: this is purely a theoretical issue. In practice, developers don't <i>care</i> that this is case, and just care that the access control logic makes sense when using it. As someone who's had to explain why fileprivate is necessary many times to new Swift developers when using extensions, I can assure you that using this proposed private definition makes more <i>intuitive</i> sense to them.</div><div><br></div><div>To sum up, please don't lessen the experience of the average Swift programmer simply because there are some gains for the more "advanced" developers; obviously not everyone can be happy, but I believe in this case this proposal will satisfy the vast vast majority of Swift programmers (aka, people not on this mailing list).</div><div><br></div><div>Riley Testut</div><div><br>On Apr 16, 2017, at 1:02 PM, Rudolf Adamkovic via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div>-1 from me.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">Using extensions for "code organization" is another word for writing spaghetti code.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">It results in types with many responsibilities. In such cases, it's time to extract collaborator types.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">But it sure looks prettier.</div><div id="AppleMailSignature"><br></div><div id="AppleMailSignature">R+</div><div id="AppleMailSignature"><br>Sent from my iPhone</div><div><br>On 7 Apr 2017, at 10:56, Jonathan Hull via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=utf-8"><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box;">What is your evaluation of the proposal?</li></ul></div></blockquote><div class=""><br class=""></div></div>Strong -1. Just rename ‘fileprivate’ to be less annoying.<div class=""><br class=""></div><div class="">This proposal will make things even worse than they are currently. We will regret it just as much, if not more than, 0025. As others have mentioned, it is actively harmful:</div><div class="">• It once again changes the meaning of private</div><div class="">• It takes away most of the actual power of private (vs fileprivate). (I was for returning to the simpler Swift 2 access, but when I did use private, I used it to limit access to just a few lines of code. This proposal gets rid of the last ounce of usefulness of ‘private’ for me, and only has the virtue of a less annoying name).</div><div class="">• It is the camel’s nose in the tent for type-based access (people will ask for future versions to be available in the type in the submodule, module, and then public… but we will be unable to give it to them)</div><div class="">• It breaks the same code that 0159 would have broken</div><div class="">• It will be a nightmare to teach/learn</div><div class=""><br class=""></div><div class="">Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. Fileprivate is the best access levels for a lot of cases, it just has an annoying name. Given our constraints, I now believe the only sane choice left to us is to make fileprivate easier to use (as opposed to making private more like it) and to get rid of the cognitive dissonance of having similar names/concepts by renaming ‘fileprivate’ to something like ‘local’. ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ should be the one being used explicitly.</div><div class=""><br class=""></div><div class="">We are likely going to have to rename ‘fileprivate’ anyway to work with submodules (that or add another access level), and ‘local’ has connotations of visible nearby… so I think it works well enough.</div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box; margin-top: 0.25em;">Is the problem being addressed significant enough to warrant a change to Swift?</li></ul></div></blockquote><div class="">Yes, access controls are a mess… but this will make them more of a mess.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box; margin-top: 0.25em;">Does this proposal fit well with the feel and direction of Swift?</li></ul></div></blockquote><div class="">No.</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box; margin-top: 0.25em;">If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?</li></ul></div></blockquote><div class="">No. I have used languages with type-based private, and I have used languages with file-based private… but never type-based that was limited to a file. You got shrimp in my chocolate (not all great tastes go well together).</div><br class=""><blockquote type="cite" class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><ul class="" style="box-sizing: border-box; padding-left: 2em; margin-top: 0px; margin-bottom: 16px; color: rgb(36, 41, 46); font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, Arial, sans-serif, 'Apple Color Emoji', 'Segoe UI Emoji', 'Segoe UI Symbol'; font-size: 16px; background-color: rgb(255, 255, 255);"><li class="" style="box-sizing: border-box; margin-top: 0.25em;">How much effort did you put into your review? A glance, a quick reading, or an in-depth study?</li></ul></div></blockquote><div class="">I have followed the discussion closely and spent a great deal of time thinking about it.</div></div><div class=""><br class=""></div><div class="">Thanks,</div><div class="">Jon</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></body></html>