> On Jun 29, 2016, at 4:07 PM, Jordan Rose via swift-evolution > <swift-evolution@swift.org> wrote: > >> >> On Jun 29, 2016, at 14:03, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >> On Wed, Jun 29, 2016 at 3:15 PM, Jordan Rose via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> > On Jun 29, 2016, at 13:13, Jose Cheyo Jimenez <ch...@masters3d.com >> > <mailto:ch...@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.
And some of us wouldn’t like that direction which means we may not end up with a solution that makes more people happy anyway at which point we’re back where we started. > > Jordan > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
