> 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

Reply via email to