<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 15 Feb 2017, at 16:31, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 14, 2017, at 3:20 AM, David Hart <<a href="mailto:david@hartbit.com" class="">david@hartbit.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class=""><br class=""></div><div class="">On 14 Feb 2017, at 09:25, Goffredo Marocchi <<a href="mailto:panajev@gmail.com" class="">panajev@gmail.com</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div class="">I disagree with that as well as I still think we are damaging the language each time we take a known concept (like access levels) and give new meanings to the same keywords. I still look baffled at the redefinition of do and the addition of repeat for example...</div><div class=""><br class=""></div><div class="">Private, the way it was before, was an admittedly curious take on how most languages mean by private and we have jumped through a lot of hoops to justify why we did not start with Java/C++/C# like access control and augmented it instead of redefining things, omitting others, and then constantly pulling the language left and right with not a lot of permanent consensus either way as this discussion and others before show.</div></div></blockquote><div class=""><br class=""></div><div class="">It's a curious take, but it is a curious take is perfectly coherent with Swift extensions. How else would you access private implementation details from an extension? But putting it in the same file, instead of having to resort to an internal access level.</div></div></div></blockquote><br class=""></div><div class="">Right. Swift is its own language distinct from Java/C++/etc. While it is intentionally designed to remain familiar (and thus reuses many keywords across the language family), it often does so with slightly different meaning / behavior. Consider ‘throw’ for example.</div><div class=""><br class=""></div><div class="">Keeping with the spirit of Swift and staying consistent with its design, I see two plausible meanings for private:</div><div class=""><br class=""></div><div class="">Private could mean either:</div><div class="">1) private to the file (Swift 2 semantics)</div><div class="">2) accessible only to the current type/scope and to extensions to that type that are in the current file.</div><div class=""><br class=""></div><div class="">I don’t think we’ve ever evaluated and debated approach #2 systematically.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I think #2 is an interesting meaning for `private`. It would have a little bit more similarity to type-scoped `private` in other languages. It would also be applicable in the vast majority of cases where `fileprivate` is currently required.</div><div class=""><br class=""></div><div class="">That said, we very much need a file-scoped access modifier. This is by far the most important as it allows us to encapsulate access to state that needs to be accessed by more than one type. I think most people could probably live with `fileprivate` for these use cases if they were allowed to use `private` for the majority of use cases where access is both within a file *and* within the same type.</div><div class=""><br class=""></div><div class="">However, as Brent points out, the SE-0025 meaning of `private` has important use cases. I would be sad to see these go. </div><div class=""><br class=""></div><div class="">The big lesson I have taken away from our experience with SE-0025 is that `private` should have remained relevant as the “soft default” file-scoped access modifier but it does not play well with extensions. It is very common to implement a type using several extensions in the same file and despite having important use cases, SE-0025 `private` does not allow for this. This means we should not have taken the `private` keyword and instead should have persisted in finding it a name that we can all live with.</div><div class=""><br class=""></div><div class="">If we could come up with a good name for this (not at all a sure thing) I think the best way forward would be:</div><div class=""><br class=""></div><div class="">* retain `fileprivate` - its slight awkwardness will be more acceptable if it indicates a more rare / unusual use case</div><div class="">* make `private` have the semantics of #2 - it will without question be the right choice in the majority of use cases</div><div class="">* give scoped access control a new keyword - we still have the ability for tighter encapsulation when necessary and a less common keyword will better highlight that intent </div></div></div></div></blockquote><div><br class=""></div><div>I’d be very strongly against adding yet another private accessor. I brought this all up to simplify the access-story, and this goes completely against that goal.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><div class="">I understand that there probably aren’t too many people in the community willing to see this level of churn in access modifiers, and probably many who would view this introduction of "yet another” private access modifier to be excessive and complex so I don’t plan to push this. But that is my two cents about what I think would be ideal. `private` would be used most of the time and we would still have the ability to widen or narrow visibility where necessary, with a more esoteric keyword that draws a reader’s attention.</div><div class=""><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Chris</div><br class=""></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></blockquote></div><br class=""></body></html>