> On Jun 29, 2016, at 4:52 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Wed, Jun 29, 2016 at 4:48 PM, Matthew Johnson <matt...@anandabits.com > <mailto:matt...@anandabits.com>> wrote: > >> On Jun 29, 2016, at 4:43 PM, Xiaodi Wu via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. >> >> FWIW, the text of SE-0025 itself makes no proposal about `private` as an >> access level for types (only, strangely, nested types). > > It proposed introducing a general access level. If any kind of limitation > regarding which declarations it applied to was intended that would have been > stated explicitly. Omission of a specific class of declaration from the list > of examples should not be interpreted as an intention to make `private` > inapplicable to those declarations. > > I don't doubt that the intent was a general access level. However, in failing > to mention top-level declarations of any sort as well as types, the proposal > itself fails to present a vision for two critical issues being discussed > here: (1) the issue of utterability; and (2) what to do when `private` and > `fileprivate` are equivalent in meaning. Both of these scenarios are > unprecedented because the three existing access levels do not have these > issues. If we had a fuller vision of the design challenges during the initial > proposal and review, these might have been resolved to more general > satisfaction before implementation was attempted.
Actually there was plenty of discussion about top level types, specifically point #2. This was considered acceptable. The recommendation is to just use private here, although that isn’t required. Unutterability is the only thing that wasn’t discussed. Maybe that would have been discovered and discussed had the proposal been written better but that is water under the bridge now. > > >> >> >> 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 <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
