> Am 25.03.2016 um 18:36 schrieb Michel Fortin via swift-evolution
> <swift-evolution@swift.org>:
>
>> Le 25 mars 2016 à 12:57, Tino Heth via swift-evolution
>> <swift-evolution@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 _______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
