> On Feb 17, 2017, at 6:10 PM, Matthew Johnson <[email protected]> wrote: > > > > Sent from my iPad > > On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez <[email protected] > <mailto:[email protected]>> wrote: > >> >> From Ted. >>> Relative to Swift 3, the bar for such changes is significantly higher: >>> >>> The existing syntax/API being changed must be actively harmful. >>> The new syntax/API must clearly be better and not conflict with existing >>> Swift syntax. >>> There must be a reasonably automatable migration path for existing code. >> >> >> I don’t think there is evidence that scope private in Swift3 is "actively >> harmful”. >> Reverting to Swift2 file-private as private is not clearly better. >> The community has not converged on a clear winner. >> >> The only positive thing here is that if we get rid of scope private then it >> will be easy to make private alias to file-private so no code will break, >> but we would be removing a feature so I would think this is a breaking >> change. >> >> Would removing private and fileprivate by making them alias to internal also >> be a breaking change? Even if the code will still compile? > > Thanks for posting this Jose. I think the point that has near unanimous > agreement is that assigning `private` the meaning of scoped access was a > mistake. `fileprivate` is too awkward given how frequently it is necessary > in common idioms of Swift code organization. > > Whether scoped access itself is a valuable feature and whether it should > remain is the question that is turning out to be very controversial. The > mistake we made with the keywords in Swift 3 certainly didn't help make the > case for it. > > That's why I would like to see us try to fix that mistake. I think everyone > can be reasonably happy if we can all use `private` the way we did in Swift 2 > and `scoped` can become a style issue. Some teams can have a linter reject > it and those of us who like it can continue using it. As a bonus, we would > eliminate an awkward keyword.
I appreciate the enthusiasm about this but the same argument can be used the other way. What about renaming `fileprivate` to `privy`. Shorter than private, typing `pri` would auto complete to it, more swifty. Win Win. :) Its going to be hard finding names for either scope private or file private that the community will agree with. Its going to be a hard sale given the other more important features being worked on. > >> >> This is a linter problem. If people don’t want other people in their team to >> use scope private then make it part of the coding style. >> >> If people do not want fileprivate because it looks ugly, then force >> everybody to use scope private using a linter like swiftlint. >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >>> On Feb 17, 2017, at 2:35 PM, Matthew Johnson via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> >>>> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> Personally I feel enforced encapsulation of implementation detail to the >>>>> latter group is less important than the former, and can be handled by >>>>> convention. Whereas other users of your module definitely benefit from >>>>> access control and being able to consume a clearly-defined interface. >>>> >>>> I think failing to provide some sort of below-`internal` privacy would be >>>> missing *really* low-hanging fruit for no good reason. The languages I can >>>> think of which don't include some sort of sub-library-wide privacy >>>> level—Objective-C, Javascript, Perl, Python—usually have very simple >>>> object designs with a flat namespace. (Well, there's Rust, but Rust lets >>>> you wrap anything you'd like in a module.) Even Objective-C in practice >>>> includes a `fileprivate` equivalent in the form of methods declared only >>>> in the .m file. >>>> >>>> I also think it's often helpful to be able to change a member's access >>>> level without having to change all references to it. Publishing or >>>> privatizing an interface is not an uncommon refactoring. >>>> >>>> Not everybody likes our current semantics, but that's no reason to throw >>>> the feature out entirely. >>> >>> +1. I’d like to see `private` revert to the Swift 2 meaning, and hopefully >>> we can reconsider using `scoped` as the keyword for scoped access rather >>> than abandoning it. Does anyone remember why this was considered a bad >>> idea? >>> >>>> >>>> -- >>>> Brent Royal-Gordon >>>> Architechies >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
