I'm aware of this, but that's fairly a long time ago - before Swift was open source and had community feedback and before Swift was used widely among developers.
To me, real-world use of the language has shown some flaws of missing a protected access control, mainly having to decide between having a variable internal or cramming all of the class extension into one file, making it a 3KLOC mess. Either solution is not pretty - now I have it split among several files with an internal variable commented as "Do not use, for private use of this class only." > On Feb 17, 2017, at 7:47 AM, Jose Cheyo Jimenez <ch...@masters3d.com> 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 > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>> >>> Sent from my iPad >>> >>>> On Feb 16, 2017, at 8:36 PM, David Sweeris via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Feb 16, 2017, at 14:34, Slava Pestov via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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 >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
