[swift-evolution] [swift-evolution-announce] [Review] SE-0169: Improve Interaction Between private Declarations and Extensions

[Jakub Suder]

Fair enough - in this case, definitely +1 on the current proposal.

Kuba

On 8 April 2017 at 06:34, John McCall <rjmccall at apple.com> wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution at 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; 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>

On 8 April 2017 at 06:34, John McCall <rjmccall at apple.com> wrote:

>
> > On Apr 7, 2017, at 8:12 PM, Jakub Suder via swift-evolution <
> swift-evolution at 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; 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 at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170408/a9e99476/attachment.html>