Fair enough - in this case, definitely +1 on the current proposal. Kuba
On 8 April 2017 at 06:34, John McCall <[email protected]> wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution < > [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. > > > 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 > > On 8 April 2017 at 06:34, John McCall <[email protected]> wrote: > > > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution < > [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. > > > 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] https://lists.swift.org/mailman/listinfo/swift-evolution
