> On Jun 29, 2016, at 10:08 AM, David Hart <da...@hartbit.com> wrote: > > Sorry if I wasn’t expressing myself well enough. In my original email, I said > that: > > > The new rules make `private` more prominent compared to `fileprivate` (the > > latter has a somewhat worse name). > > So I agree that my issue is more with the naming than the functionality. I’m > mainly complaining that because of its name, `fileprivate` feels like more of > a special corner case of `private`. But in the style of writing types through > extensions, `fileprivate` will become much more prevalent than `private`, > which feels slightly backwards.
I don’t view it as more of a special corner case at all, but I can see why you feel that way since it has an unprecedented (AFAIK) and more verbose name. The proposal originally left `private` alone and used a new name for the new access level. We weren’t able to find a name that didn’t have problems which led to the idea of renaming the existing `private`. My perspective is that it’s just the best name we could come up with for the concept in the context of the various access levels we want to support. The name isn’t intended to discourage use in any way. > > But I don’t want to dabble too much about it. If its the way it’s going to > be, so be it. > >> On 29 Jun 2016, at 15:11, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >> There is nothing preventing you from using fileprivate if you want to write >> your code in this style. At most you can complain that you don't like the >> new keyword. But you're not losing any functionality so I don't understand >> why you say you are "missing" something. >> >> Sent from my iPad >> >> On Jun 29, 2016, at 1:25 AM, David Hart via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >>> >>>> On 29 Jun 2016, at 04:03, Matthew Judge <matthew.ju...@gmail.com >>>> <mailto:matthew.ju...@gmail.com>> wrote: >>>> >>>> If I understand SE-0025 (even with the amendment) you can still spell the >>>> access modifier to types as 'private' and get the same characteristics as >>>> the pre-SE-0025 meaning or private, so I'm not sure I understand the >>>> concern here. However (continued below) >>> >>> The characteristic I will be missing is for the following style of writing: >>> >>> class MyViewController : UIViewController { >>> private var privateInfo: String? >>> } >>> >>> //MARK: Public >>> >>> public extension MyViewController { >>> func publicFunction() { >>> // CAN’T ACCESS privateInfo >>> } >>> } >>> >>> //MARK: UITableViewDataSource >>> >>> private extension MyViewController : UITableViewDataSource { >>> func numberOfRowsInSection(_ section: Int) -> Int >>> // CAN’T ACCESS privateInfo >>> } >>> } >>> >>> //MARK: Private >>> >>> private extension MyViewController { >>> func implementationFunction() { >>> // CAN’T ACCESS privateInfo >>> } >>> } >>> _______________________________________________ >>> 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