[swift-evolution] [Discussion] A Problem With SE-0025?

[Xiaodi Wu]

On Wed, Jun 29, 2016 at 4:07 PM, Jordan Rose <jordan_rose at apple.com> wrote:

>
> On Jun 29, 2016, at 14:03, Xiaodi Wu <xiaodi.wu at gmail.com> wrote:
>
> On Wed, Jun 29, 2016 at 3:15 PM, Jordan Rose via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>>
>>
>> > On Jun 29, 2016, at 13:13, Jose Cheyo Jimenez <cheyo at masters3d.com>
>> wrote:
>> >
>> > I know this might be have been brought up before but
>> >
>> > why not just disallow the “private" keyword for top level types,
>> extensions etc.
>> >
>> > A fixit could change top level `private` to `fileprivate`.
>> >
>> > I think this is a little less confusing since effectively this is what
>> is happening in the background.
>>
>> That doesn’t fix anything for inner types, so it’s a lot less important
>> than the rest of the amendment.
>>
>> 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.
>>
>
> On second thought, wouldn't all of this be inapplicable if `private`
> literally meant visibility *only* within the current declaration, and
> neither outside it nor inside any nested types, etc.?
>
>
> Yes, but that's not very useful:
>
> public struct Foo {
>   private var value: Int = 0
>   public func test() {
>     print(value) // error
>   }
> }
>
>
> I suppose you could say that nested *types* are different from nested
> *functions,* but then we start getting complexity in a different
> direction. And it still doesn't fix the default access within a private
> type.
>

Let me offer a principled rule: if I write `private var foo`, then `foo` is
invisible at such places within the declaration where writing `private var
bar` at the same place would cause `bar` to be visible where `foo` is not
or vice versa.


> Jordan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160629/e37e0bd9/attachment.html>