Sent from my iPad
> On Feb 17, 2017, at 6:52 PM, Jose Cheyo Jimenez <[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. > > 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]> wrote: >>> >>> >>>> On Feb 17, 2017, at 4:29 PM, Brent Royal-Gordon via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> On Feb 17, 2017, at 12:29 AM, Slava Pestov via swift-evolution >>>> <[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] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
