> On Apr 8, 2017, at 4:12 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > > On Fri, Apr 7, 2017 at 11:34 PM, John McCall via swift-evolution > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution > > <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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. > > > 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; > > If I recall correctly, Chris in post-review discussions communicated that a > new keyword to replace `fileprivate` would be considered if `fileprivate` > turned out to be commonly used enough to be aesthetically problematic?
Yes. We would consider it. Chris probably believes that we're more likely to accept that change than I do; that's why I was careful to say that I was just speaking for myself. (Chris didn't need to say that explicitly in his message because he wasn't explicitly speaking for the Core Team in other parts.) > I bring this up because, in replying to BJ Homer, it occurs to me that there > is an interesting solution. If--as I understand--successive access modifiers > being supersets of preceding ones is a non-negotiable part of the design, > then type-based access modifiers cannot be accommodated in Swift because of > the existence of extensions. Ergo, the word "protected" cannot ever be used > to mean what it does in C++, etc. It is a perfectly nice word that by its > dictionary meaning is plausibly intermediate between "private" and > "internal," which we can repurpose to mean protected by the end of file! By > co-opting this word, it has the key virtue of definitively demonstrating that > Swift cannot and will not support access modifiers that are tied to types. I wouldn't say that successive access modifiers being supersets of existing ones is a part of the design. We've been reluctant to change *existing* modifiers in ways that aren't just weakening them, but that's different. That said, "protected" is a pretty valuable keyword, and there have been several other interesting proposals for it, especially for things that lie on the other side of "internal". I wouldn't want to burn "protected" until we've gotten a complete enough picture of what access problems library developers are having that we're sure it's not more useful there. John. > > 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 > > 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
