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

[Charlie Monroe]

> On Mar 21, 2017, at 6:43 PM, Jose Cheyo Jimenez <cheyo at masters3d.com> wrote:
> 
>> 
>> On Mar 21, 2017, at 1:10 AM, Charlie Monroe via swift-evolution <swift-evolution at swift.org <mailto: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)

Yes, 19 cases (out of those 160). Mostly for private classes or identifiers/constants.

In another project (a framework I use in all my projects):

private (total): 335
top-level private: 65 (out of those 335)
fileprivate: 41

And I know about a place or two that's not properly written and if I refactored it properly, I'd get rid of another 20 fileprivates.

In my experience (for me - please don't take it as if I am judging anyone - not at all), the use of fileprivate indicates either improper public API (and by public I mean even internal - exposed out of the file); or that there could be other mechanisms for handling this (protected scope for subclasses/enclosing types).

> 
> 
> 
>> 
>> 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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <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/26f52900/attachment.html>