> On 15 Feb 2017, at 23:15, Matthew Johnson <[email protected]> wrote: > >> >> On Feb 15, 2017, at 4:12 PM, David Hart <[email protected] >> <mailto:[email protected]>> wrote: >> >>> >>> On 15 Feb 2017, at 16:31, Matthew Johnson <[email protected] >>> <mailto:[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. > > Yes, I understand that a lot of people feel strongly that way. I don’t > expect this to be adopted, I just wanted to offer my opinion.
Sorry if I came across as violent in my response, I was just being passionate :) Your opinion is of great value to me! >> >>> 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 >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
