>> On Mar 29, 2016, at 13:54, Chris Lattner via swift-evolution 
>> <[email protected]> wrote:
>> 
>> On Mar 25, 2016, at 10:37 AM, Kevin Lundberg via swift-evolution 
>> <[email protected]> wrote:
>> I use the file-private scope a fair amount for top-level constants that are 
>> intended to be used within the file, possibly across types. Doing things 
>> this way is more concise than embedding them as static members in the type 
>> itself since I don't need to qualify them with the name of the type at the 
>> front.
> 
> This is a great point, and perhaps should be made more clear.  In the 
> degenerate case of a top level declaration, “private” and “fileprivate” are 
> the same thing, since the scope that “private” refers to is the whole file.
> 
>   private let c = 42   // usable within the current file.
> 
>   private struct X { init(a : Int) {…} }  // usable within the current file.
> 
>   func foo() { 
>           let thing = X(a: c)
>   }
> 
> -Chris

This seems to be a strong argument for "private(file)" or "private(#file)" 

There are really just two access levels:
- public // visible everywhere
- private // only visible to current scope

The parenthetical is a way to refer to some enclosing scope broader than the 
current scope.

- Matt

> 
>> 
>> Kevin Lundberg
>> [email protected]
>> 
>> 
>> 
>>> On Mar 25, 2016, at 1:11 PM, Erica Sadun via swift-evolution 
>>> <[email protected]> wrote:
>>> 
>>> 
>>>> On Mar 25, 2016, at 10:57 AM, Tino Heth via swift-evolution 
>>>> <[email protected]> wrote:
>>>> 
>>>> 
>>>>> These are special cases — both file-private and module-private is 
>>>>> something that is fairly unusual
>>>> 
>>>> afaics this is the third time someone mentions that "file-private" is 
>>>> uncommon — so I think it's time someone dissents:
>>>> That statement is at least subjective… right now, "file-private" is one of 
>>>> three access levels, and I wouldn't dare to say either is more or less 
>>>> important than the others.
>>>> 
>>>> I never encountered situations with the current model where I missed a new 
>>>> "private"-level, and maybe "private" will become fairly unusual for the 
>>>> code I'll be writing.
>>>> 
>>>> In my existing code, the new meaning of private wouldn't break much, but 
>>>> the current meaning doesn't hurt me, and there are cases where 
>>>> "file-private" is needed.
>>>> 
>>>> None the less, I don't care much about the "ugliness" of "fileprivate" — 
>>>> but not because I perceive it as unusual:
>>>> I just expect that code completion will do the typing for me, so maybe "f" 
>>>> will be all I have to write (half the characters of "pr" ;-)
>>> 
>>> I cannot come up with a single use-case in my code for fileprivate and 
>>> would love
>>> some real world examples where you'd want visibility in a single file but 
>>> not across
>>> an entire module.
>>> 
>>> The fileprivate behavior has been a bugaboo of mine for some time, 
>>> particularly in 
>>> playground use. 
>>> 
>>> As far as I'm concerned, the control I really want is public,  
>>> intra-modular, private, and 
>>> private-even-to-extensions-and-subclasses. I assume the latter is a no-go.
>>> 
>>> -- E
>>> 
>>> 
>>> 
>>> 
>>> _______________________________________________
>>> swift-evolution mailing list
>>> [email protected]
>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected]
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to