> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution > <swift-evolution@swift.org> wrote: > > >> On Mar 21, 2017, at 8:26 AM, Slava Pestov <spes...@apple.com >> <mailto:spes...@apple.com>> wrote: >> >>> >>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> -1 on this as well for similar reasons. Places where I use fileprivate >>> (aside from what was automatically migrated by Xcode) can be counted on >>> fingers of one or two hands. >>> >>> I feel that this proposal is reverting something without offering an >>> alternative solution. >> >> In what situations do you use Swift 3 private where fileprivate is not an >> acceptable replacement? > > In my usage, I very rarely use fileprivate. To back this with numbers, a > recent project I developed (i.e. without Xcode's automatic migration of > private -> fileprivate; about 6KLOC) has 2 uses of "fileprivate" and 160 uses > of "private”.
Do you have a way to tell how much of the private is effectible fileprivate? (top level private usage) > > This is definitely a personal opinion, but I tend to limit access to members > as much as possible to discourage/prevent their usage out of the scope they > are intended for and to better design API that should be used out of the > scope (public/internal). I feel this is a good thing for newcomers to a > codebase (and myself coming back to a codebase after a year or two) as > Xcode's autocompletion won't offer members that are not supposed to be called > out of the scope (scope-private). > > As I've mentioned this during the discussion, I feel that current state of > things encourages huge files (1000+ lines of code) as you can't define > "protected" level access and migrate some of the code that implements e.g. > accessibility to a different file without potentially exposing internal > details to the rest of the module (if the extension in the other file needs > access to private details, which is often the case). > > I feel that if there should be a change to the access levels, it should > address this as well. The current solution based on reverting the original > proposal only unnecessarily exposes implementational details to the rest of > the file - at least in my codebase. > >> >> Slava >> >>> >>>> On Mar 21, 2017, at 3:33 AM, Greg Parker via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> >>>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgre...@apple.com >>>>> <mailto:dgre...@apple.com>> wrote: >>>>> >>>>> Hello Swift community, >>>>> >>>>> The review of SE-0159 "Fix Private Access Levels" begins now and runs >>>>> through March 27, 2017. The proposal is available here: >>>>> >>>>> https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md >>>>> >>>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0159-fix-private-access-levels.md> >>>> -1. I yield the remainder of my time to Drew Crawford who satisfactorily >>>> explained my concerns. >>>> >>>> >>>> -- >>>> Greg Parker gpar...@apple.com <mailto:gpar...@apple.com> Runtime >>>> Wrangler >>>> >>>> >>>> _______________________________________________ >>>> 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
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
