> On 15 Feb 2017, at 16:31, Matthew Johnson <[email protected]> wrote: > > >> On Feb 14, 2017, at 11:31 PM, Chris Lattner via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >>> On Feb 14, 2017, at 3:20 AM, David Hart <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>> >>> On 14 Feb 2017, at 09:25, Goffredo Marocchi <[email protected] >>> <mailto:[email protected]>> wrote: >>> >>>> 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... >>>> >>>> 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. >>> >>> 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. >> >> 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. >> >> Keeping with the spirit of Swift and staying consistent with its design, I >> see two plausible meanings for private: >> >> Private could mean either: >> 1) private to the file (Swift 2 semantics) >> 2) accessible only to the current type/scope and to extensions to that type >> that are in the current file. >> >> I don’t think we’ve ever evaluated and debated approach #2 systematically. > > 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. > > 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. > > However, as Brent points out, the SE-0025 meaning of `private` has important > use cases. I would be sad to see these go. > > 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. > > 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: > > * retain `fileprivate` - its slight awkwardness will be more acceptable if it > indicates a more rare / unusual use case > * make `private` have the semantics of #2 - it will without question be the > right choice in the majority of use cases > * 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
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. > 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. > > >> >> -Chris >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
