[swift-evolution] SE-0025: Scoped Access Level, next steps

[Thorsten Seitz]

> Am 25.03.2016 um 18:36 schrieb Michel Fortin via swift-evolution <swift-evolution at swift.org>:
> 
>> Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution <swift-evolution at swift.org> a écrit :
>> 
>> afaics this is the third time someone mentions that "file-private" is uncommon — so I think it's time someone dissents:
> 
> I'll do the same. There's many instances in my code where I rely on the file-private behavior of Swift 2's private. Mostly this happens when I have a pair of coupled classes that are meant to be used together and that need to access internal details of each other. Most declarations can be scope-private without problem, but it's not that uncommon for me to take advantage of file-private. 

+1


> 
> There's another aspect that is bothering me about these long names. It seems that everyone agrees that writing internal is a rare thing. Still, if you look at generated headers in Xcode you'll see internal everywhere, like this:
> 
> internal class ItemDataModel {
>     internal var storage: ItemStorage { get set }
>     internal let fileType: String
>     required internal init(fileType: String, storage: ItemStorage = default)
> }
> 
> Since internal is the default, it's quite common in generated headers. "moduleprivate" wouldn't be an improvement for legibility here. But perhaps no one but me looks at generated headers for my own project.

Additionally Jordan noted that there might be a policy to always use explicit access control. In our Java projects we certainly do this because the default "package" level is quite unusual there and omitting it is easily intepreted as being an oversight instead of intentional.

-Thorsten 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160329/c72be105/attachment.html>