My ideal scenario: 1) Go back to Swift 2 meaning of private
2) Add the ‘hidden’ axis I talked about in another thread. This will provide the capabilities of protected + friend (and allow extensions organized across files) using a consistent file-based approach that is easy to reason about. It also neatly avoids the issues mentioned in the blog post. Thanks, Jon > On Feb 16, 2017, at 10:47 PM, Jose Cheyo Jimenez via swift-evolution > <[email protected]> wrote: > > https://developer.apple.com/swift/blog/?id=11 > <https://developer.apple.com/swift/blog/?id=11> > > > > On Feb 16, 2017, at 10:05 PM, Charlie Monroe via swift-evolution > <[email protected] <mailto:[email protected]>> wrote: > >> How about removing fileprivate, getting Swift 2 meaning of private (as most >> people here now suggest) and add additional @protected annotation for those >> who want a more fine-grained solution: >> >> @protected private - members accessable only from the class/struct/enum/... >> and their extensions within the file >> >> @protected internal - again, but you can access it even from extensions and >> subclasses outside of the file within the entire module. >> >> @protected public/open - the same as above, but outside the modules. >> >> To me, this way most people here will be happy: >> >> - those wishing the access control gets simplified - it in fact does, you >> don't need to use @protected, if you don't want to/need to. >> - those who need a fine-grained solution, here it is. >> >> >> >>> On Feb 17, 2017, at 3:49 AM, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>> >>> Sent from my iPad >>> >>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>> >>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> While we’re bikeshedding, I’m going to add my two cents. Hold on to your >>>>> hat because this might be controversial here. >>>>> >>>>> I think both ‘private’ and ‘fileprivate’ are unnecessary complications >>>>> that only serve to clutter the language. >>>>> >>>>> It would make a lot more sense to just have internal and public only. No >>>>> private, no fileprivate, no lineprivate, no protected. It’s all silly. >>>> >>>> Eh, I've used `private` to keep myself honest in terms of going through >>>> some book-keeping functions instead of directly accessing a property. >>> >>> This is exactly the kind of thing I like it for and why I hope we might be >>> able to keep scoped access even if it gets a new name that ends up as >>> awkward as fileprivate (allowing private to revert to the Swift 2 meaning). >>> >>>> >>>> - Dave Sweeris >>>> _______________________________________________ >>>> 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] <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] <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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
