> On 8 Apr 2017, at 2:34 pm, John McCall via swift-evolution > <[email protected]> wrote: > >> >> On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >>> What is your evaluation of the proposal? >> >> If this is the last option we have to change the status quo, any renaming is >> off the table, no further changes after Swift 4, and it's either this or >> being stuck with 'fileprivate' until the end of time, then +1 from me. It >> will increase the convenience of access control for people like me who see >> types and their extensions as parts of the same entity, just spread visually >> across neighboring blocks. In almost any other language these two would >> indeed be one entity, since most languages don't have any way of dividing >> types into pieces this way. >> >> However, IMHO any of these would be a better solution: > > I'd like to respond briefly to this to clarify the Core Team's decisions > about what solutions are under consideration, both now and in the future. By > doing this, I don't mean to pressure you towards any particular stance. The > Core Team asked for this to be proposed because we wanted to know how the > community felt about it; we are not specifically trying to get it approved, > at least as a group. > >> 1) Rename 'private' to something else ('scoped'?) and rename 'fileprivate' >> back to 'private' > > The Core Team has rejected making such a major change in the interpretation > of 'private'. 'private' will be tied to scopes, now and forever. The only > question is whether extensions of the same type within a file should be > considered part of the same scope for the purposes of 'private'. Swift 4 is > the deadline for making that change; if it, too, is rejected, 'private' will > be purely lexical forever.
With this being the case, I want to revise my response to +1. It allows the flexibility required for the extension-rich architecture Swift open adopts with protocol conformance and I think that’s a good thing, personally. > >> 2) Rename 'fileprivate' to something more friendly (I liked the 'local' >> suggestion that Vladimir made today) > > The Core Team is willing to consider adding a new keyword to replace > 'fileprivate', but not in Swift 4. > > Speaking just for myself, I don't think we'd accept such a change purely for > aesthetics; it would have to be because 'fileprivate' seemed inappropriate > for some new generalization, e.g. if we added sub-file submodules and wanted > 'fileprivate' to allow access only within the submodule. That is assuming a > lot about how a future submodule feature would work, and we aren't going to > design that feature specifically with a goal of replacing this keyword, and > frankly we don't know when we're going to take that on at all. I would > caution people against assuming that 'fileprivate' will be renamed. > >> 3) Postpone this until we add submodules, but with the assumption that it >> will be possible to make some source-breaking changes at that point > > The Core Team is not willing to change the basic design of 'private' in > future releases of Swift. If some feature — perhaps submodules — demands > that we define its interaction with 'private', the design of that interaction > will have to feel natural and consistent with the at-that-point extant design > of 'private'. For example, it would not be acceptable if, say, adding a > submodule declaration to a file suddenly changed the interpretation of > 'private'. > > An option (4) that you didn't list but which I should cover for completeness > would be to add new keywords in the future with new interpretations. This is > something that the Core Team is willing to consider. However, speaking just > for myself again, I find it unlikely that we would add new access control > features just to express increasingly-precise refinements; it would have to > be something that felt necessary because of some real inadequacy in the > existing access-control levels as applied to some other new feature (e.g. > submodules). > > John. > >> The thing I don't like about this proposal (or status quo) - apart from the >> fact that it will make people who like the current strict private unhappy - >> is that 'private' even right now means kind of two different things: >> >> - for a property or a method defined in a class/struct, it means "available >> only inside this type" >> - for a private global variable/constant/function, or a private type or >> extension, it means "available in this file" i.e. the same as 'fileprivate' >> >> So if we're worried that this proposal makes the meaning of 'private' >> unclear - it already is unclear. Wouldn't it be much more clear if private >> global variables, functions and classes were required to use the access >> level that means "available in this file", since that's how they actually >> work? (as long as this level is not named 'fileprivate' :) >> >> And the other access level, the "available only inside this type" (private / >> scoped), could only be used for things that are actually contained inside a >> type, and wouldn't have two different meanings depending on whether it's at >> the root of the file or nested inside something else. >> >> I really believe that even though this is kind of painful for everyone, it's >> worth spending time to figure out a solution that satisfies most of us and >> makes the language clearer and friendlier in the long term, even if it means >> breaking compatibility again. Do we want to be stuck with an imperfect >> solution 10 years from now, because we didn't want to do this last breaking >> change now? >> >> >>> Is the problem being addressed significant enough to warrant a change to >>> Swift? >> >> I think almost everyone here agrees it is significant. >> >> >>> Does this proposal fit well with the feel and direction of Swift? >> >> This is a difficult question. IMHO it would definitely fit much better with >> the direction of Swift if we bit the bullet and did whatever we agree will >> make the language simpler and better long term, regardless how many changed >> lines in git this will cause when Swift 4 is released. >> >> >>> If you have used other languages or libraries with a similar feature, how >>> do you feel that this proposal compares to those? >> >> I've used many languages, but I think in none of them it was a common thing >> (or even a possibility) to split types into several blocks like we do in >> Swift with extensions, so the main issue we're talking about didn't exist >> there. In Ruby you can kind of do the same thing with modules - if you have >> a private method in a module, you can access it from methods in the main >> type, even if they're defined in a different file. (But Ruby isn't very >> strict about access control in general, e.g. it allows you to call private >> methods on any object via #send). >> >> >>> How much effort did you put into your review? A glance, a quick reading, or >>> an in-depth study? >> >> I've read or skimmed through most of the messages in the recent threads >> about this and the last proposal. >> >> Disclaimer: I have very little experience with Swift 3 (but plenty with >> Swift 2.x). >> >> Kuba >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> 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
