[swift-evolution] [swift-evolution-announce] [Review] SE-0159: Fix Private Access Levels

[Jose Cheyo Jimenez]

> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 21, 2017, at 8:26 AM, Slava Pestov <spestov at apple.com <mailto:spestov at apple.com>> wrote:
>> 
>>> 
>>> On Mar 20, 2017, at 11:07 PM, Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>>> On Mar 20, 2017, at 4:54 PM, Douglas Gregor <dgregor at apple.com <mailto:dgregor at 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     gparker at apple.com <mailto:gparker at apple.com>     Runtime Wrangler
>>>> 
>>>> 
>>>> _______________________________________________
>>>> swift-evolution mailing list
>>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/297ca81b/attachment.html>