[swift-evolution] [Discussion] A Problem With SE-0025?
mailing at xenonium.com
Thu Jun 30 01:26:17 CDT 2016
> Le 30 juin 2016 à 01:10, Matthew Johnson via swift-evolution <swift-evolution at swift.org> a écrit :
>> On Jun 29, 2016, at 6:07 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>>> On 29 Jun 2016, at 22:15, Jordan Rose via swift-evolution <swift-evolution at swift.org> wrote:
>>> There actually is an answer to this, which is that the core team expects 'private' to be the common keyword, and therefore it’s better if you can use it at the top level and ignore ‘fileprivate’ altogether in most programs.
>> This makes no sense to me for two reasons:
>> 1) As I previously said, I don't expect `private` to be the common keyword if people keep writing types as a main declaration and a set of extensions. With that style, we'll be using `fileprivate` heavily for properties in the main declaration.
> It’s clear that *some* people are writing Swift this way. But I don’t think it is the most common style. I think it’s more common to put “core” members inside the type declaration. With that style the need for `fileprivate` is minimized.
All sample code encourage writing extension for protocol, and when writing an application, a lot of classes implements delegate protocol. For what I can see in my own code, there is a lot of places where I will have to change to fileprivate instead of private to make it compile.
>> 2) If private means only visible to its lexical scope, I would have expected private top level declarations to be visible to the global scope, which is equivalent to `internal` for me, no `fileprivate`.
> Files introduce a scope in the same sense that modules do.
>> I'm getting more and more confused about SE-0025.
>> swift-evolution mailing list
>> swift-evolution at swift.org
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution