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

-1 (strong)

I think I've read all messages and haven't much to add — so just to sum up my concerns in order:
— It makes access control more complicated
For me, it's not about the complexity itself (it's not terrible huge, after all), but I believe in the beauty of simplicity, which is already quite flawed.
— It adds no power to the language
The proposal solves no real problem, but rather encourages a certain style of programming, which is quite popular among authors of styleguides, but has no clear net gain.
— It diminishes the need for fileprivate without making it redundant
It would be nice to get rid of an access level, but having four common ones and fileprivate as an exotic outlier doesn't feel right for me.
— It is a mockery for SE-0025
I never liked "new private", but it was decided that this sort of encapsulation is important enough to justify 33% increase in the number of access levels, so I don't like to see this watered down
— It is a breaking change
For me personally, that doesn't really count as an argument on its own, and I would gladly take the inconvenience of incompatibility in exchange for a tiny improvement of the language; but in combination with the other points, it increases opposition.

I spend some time thinking about nested extensions (which would achieve the goal of this proposal naturally) and think that SE-0169 would lead to some questionable possibilities of short-circuiting access control:

class Outer {
  private class Inner {
    private var x = 0
  }
}

/*
.
.
.
*/

extension Outer.Inner {
  public func f() {
    print(x)
  }
}

As I read the proposal, there is no doubt that this would be allowed — but without that detailed information, I'm not sure if anybody would expect that two levels of private still is not enough to keep something secret…

- Tino

I cannot express how strongly I believe this is the direction Swift should go, so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself. I think that the functionality provided by fileprivate is valuable, and I also agree it shouldn’t be the default.

However

This proposal would solve the problems introduced by Swift 3’s private, which has resulted in me defaulting to fileprivate for almost all “private” variables due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they initially are confused why private doesn’t work for extensions. To them, it does not feel intuitive, and it certainly doesn’t to me either.

One argument I saw throughout these discussions was that this encourages people to put all their code in one file. To that I ask, how is this any different than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things almost exactly the same as what we have now, but addresses the concerns of many in the Swift community. If you don’t want to use private with extensions, people can simply not use private variables in extensions.

I genuinely believe this will satisfy the majority who were upset by fileprivate, and I do not think it will affect those who were in favor of fileprivate. So yes, again +10000, and let’s please be done with this fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some others. I would be very happy if this was the private/fileprivate solution forever).

···

On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for discussion in Swift 4 (or any later release), given the significant impact on source compatibility>>, because SE-0169 is also a source breaking change, and the problem of access modifiers is important enough to relax the rule of source compatibility for it, *especially if this is the last chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private Access Levels) which also has impact on source compatibility(given it suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
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

While valid, my understanding is that the use of extensions that should have access to private members is more common than the use of extensions to explicitly prevent access.

More importantly though, using extensions to prevent access to private members can be accomplished by declaring the extensions in another file. The reverse is not true; extensions that should have access to private members is impossible.

tl;dr; using extensions as a means to disallow access to private members is (from what I understand) far less common, and if someone really wanted to do that, they could instead declare the extensions in another file.

···

On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution <swift-evolution@swift.org> wrote:
I cannot express how strongly I believe this is the direction Swift should go, so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself. I think that the functionality provided by fileprivate is valuable, and I also agree it shouldn’t be the default.

However

This proposal would solve the problems introduced by Swift 3’s private, which has resulted in me defaulting to fileprivate for almost all “private” variables due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they initially are confused why private doesn’t work for extensions. To them, it does not feel intuitive, and it certainly doesn’t to me either.

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

One argument I saw throughout these discussions was that this encourages people to put all their code in one file. To that I ask, how is this any different than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things almost exactly the same as what we have now, but addresses the concerns of many in the Swift community. If you don’t want to use private with extensions, people can simply not use private variables in extensions.

I genuinely believe this will satisfy the majority who were upset by fileprivate, and I do not think it will affect those who were in favor of fileprivate. So yes, again +10000, and let’s please be done with this fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some others. I would be very happy if this was the private/fileprivate solution forever).

On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for discussion in Swift 4 (or any later release), given the significant impact on source compatibility>>, because SE-0169 is also a source breaking change, and the problem of access modifiers is important enough to relax the rule of source compatibility for it, *especially if this is the last chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private Access Levels) which also has impact on source compatibility(given it suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

My previous email was in response to this sorry. Ugh, mailing lists.

···

On Apr 6, 2017, at 5:43 PM, Riley Testut <rileytestut@gmail.com> wrote:

While valid, my understanding is that the use of extensions that should have access to private members is more common than the use of extensions to explicitly prevent access.

More importantly though, using extensions to prevent access to private members can be accomplished by declaring the extensions in another file. The reverse is not true; extensions that should have access to private members is impossible.

tl;dr; using extensions as a means to disallow access to private members is (from what I understand) far less common, and if someone really wanted to do that, they could instead declare the extensions in another file.

On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution <swift-evolution@swift.org> wrote:
I cannot express how strongly I believe this is the direction Swift should go, so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself. I think that the functionality provided by fileprivate is valuable, and I also agree it shouldn’t be the default.

However

This proposal would solve the problems introduced by Swift 3’s private, which has resulted in me defaulting to fileprivate for almost all “private” variables due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they initially are confused why private doesn’t work for extensions. To them, it does not feel intuitive, and it certainly doesn’t to me either.

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

One argument I saw throughout these discussions was that this encourages people to put all their code in one file. To that I ask, how is this any different than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things almost exactly the same as what we have now, but addresses the concerns of many in the Swift community. If you don’t want to use private with extensions, people can simply not use private variables in extensions.

I genuinely believe this will satisfy the majority who were upset by fileprivate, and I do not think it will affect those who were in favor of fileprivate. So yes, again +10000, and let’s please be done with this fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some others. I would be very happy if this was the private/fileprivate solution forever).

On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for discussion in Swift 4 (or any later release), given the significant impact on source compatibility>>, because SE-0169 is also a source breaking change, and the problem of access modifiers is important enough to relax the rule of source compatibility for it, *especially if this is the last chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private Access Levels) which also has impact on source compatibility(given it suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Presumably, proponents of SE-0025. That is, after all, an explicit part of that design, reviewed and approved by the Swift community and core team.

I'd be curious how many people actually are doing this though. My understanding is this practice is not that common overall.

Ultimately though, yes with any change like this there will be compromises. I personally believe the loss of this situation you're describing is far less than what there is to gain from this proposal.

···

On Apr 6, 2017, at 5:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka <cocoadev@charlessoft.com> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

Presumably, proponents of SE-0025. That is, after all, an explicit part of that design, reviewed and approved by the Swift community and core team.

Me.

Even though I think we were better off without scoped `private`, I *have* used it fruitfully on several occasions. These were typically in places where I wanted to restrict access to a small number of members which I could ensure would enforce certain invariants. An example I gave previously involved two arrays which contained matching elements; code should never insert or remove from one array without doing the same to the other. By making these arrays `private` and exposing `fileprivate` and `public` members derived from them, I could ensure that only a couple dozen lines could possibly contain such a bug without changing the external design of the type or introducing boilerplate.

This proposal does not offer the same utility. The only way to protect fragile parts of a type from other parts is to extract them into a separate type, and even then, you can extend that new type anywhere in the file to access the fragile parts. You're also likely to end up having members on the outer type which simply call into equivalent members on the inner type. It increases boilerplate and reduces protection.

Despite having used scoped `private` in the past, if the choice were between keeping it and giving it `fileprivate` semantics, I would still support the latter; I think the simplification would be worth the loss of tight encapsulation. But this proposal offers *neither* simplification *nor* tight encapsulation, so I'm opposed to it.

···

On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

--
Brent Royal-Gordon
Architechies

I cannot express how strongly I believe this *is *the direction Swift
should go, so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself.
I think that the functionality provided by fileprivate is valuable, and I
also agree it shouldn’t be the default.

*However*

This proposal would solve the problems introduced by Swift 3’s private,
which has resulted in me defaulting to fileprivate for almost all “private”
variables due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they
initially are confused why private doesn’t work for extensions. To them, it
does not feel intuitive, and it certainly doesn’t to me either.

`private` works for extensions exactly how the authors of SE-0025 intended
it to do. Your comments do not address what would happen for those people
who are making use of this functionality currently to isolate methods to
the extension only.

···

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution < swift-evolution@swift.org> wrote:

One argument I saw throughout these discussions was that this encourages
people to put all their code in one file. To that I ask, how is this any
different than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things *almost exactly the same* as what we have
now, but addresses the concerns of many in the Swift community. If you
don’t want to use private with extensions, people can simply *not use
private variables in extensions.*

I genuinely believe this will satisfy the majority who were upset by
fileprivate, and I do not think it will affect those who were in favor of
fileprivate. So yes, again +10000, and let’s *please* be done with this
fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some
others. I would be very happy if this was the private/fileprivate solution
forever).

On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution < > swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really
solution but not a workaround, then just leave the things where they are
currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for
discussion in Swift 4 (or any later release), given the significant impact
on source compatibility>>, because SE-0169 is also a source breaking
change, and the problem of access modifiers is important enough to relax
the rule of source compatibility for it, *especially if this is the last
chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private
Access Levels) which also has impact on source compatibility(given it
suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we
need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0169-improve-interaction-between-private-
declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       https://github.com/apple/swift-evolution/blob/
master/proposals/0169-improve-interaction-between-private-
declarations-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/
master/process.md#what-goes-into-a-review-1>What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Who is currently doing that?

Charles

···

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Presumably, proponents of SE-0025. That is, after all, an explicit part of
that design, reviewed and approved by the Swift community and core team.

···

On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka <cocoadev@charlessoft.com> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution < > swift-evolution@swift.org> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended
it to do. Your comments do not address what would happen for those people
who are making use of this functionality currently to isolate methods to
the extension only.

Who is currently doing that?

While valid, my understanding is that the use of extensions that *should *have
access to private members is more common than the use of extensions to
explicitly prevent access.

More importantly though, using extensions to prevent access to private
members can be accomplished by declaring the extensions in another file.
The reverse is not true; extensions that *should* have access to private
members is impossible.

tl;dr; using extensions as a means to disallow access to private members
is (from what I understand) far less common, and if someone really wanted
to do that, they could instead declare the extensions in another file.

Not if those extensions are to access fileprivate members of the type. This
is the same argument that was rejected for SE-0159.

···

On Thu, Apr 6, 2017 at 7:43 PM, Riley Testut <rileytestut@gmail.com> wrote:

On Apr 6, 2017, at 5:34 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Apr 6, 2017 at 7:28 PM, Riley Testut via swift-evolution < > swift-evolution@swift.org> wrote:

I cannot express how strongly I believe this *is *the direction Swift
should go, so a huge, gigantic,

+1
from me.

After thinking it over, I do not have any qualms with fileprivate itself.
I think that the functionality provided by fileprivate is valuable, and I
also agree it shouldn’t be the default.

*However*

This proposal would solve the problems introduced by Swift 3’s private,
which has resulted in me defaulting to fileprivate for almost all “private”
variables due to my heavy use of extensions.

Beyond me, however, I can attest that when teaching others Swift, they
initially are confused why private doesn’t work for extensions. To them, it
does not feel intuitive, and it certainly doesn’t to me either.

`private` works for extensions exactly how the authors of SE-0025 intended
it to do. Your comments do not address what would happen for those people
who are making use of this functionality currently to isolate methods to
the extension only.

One argument I saw throughout these discussions was that this encourages
people to put all their code in one file. To that I ask, how is this any
different than what we have now? Fileprivate doesn’t fix this either.

Ultimately, this keeps things *almost exactly the same* as what we have
now, but addresses the concerns of many in the Swift community. If you
don’t want to use private with extensions, people can simply *not use
private variables in extensions.*

I genuinely believe this will satisfy the majority who were upset by
fileprivate, and I do not think it will affect those who were in favor of
fileprivate. So yes, again +10000, and let’s *please* be done with this
fileprivate/private debate after this.

(Also, I personally don’t view this as a “temporary workaround” like some
others. I would be very happy if this was the private/fileprivate solution
forever).

On Apr 6, 2017, at 5:05 PM, Vladimir.S via swift-evolution < >> swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really
solution but not a workaround, then just leave the things where they are
currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for
discussion in Swift 4 (or any later release), given the significant impact
on source compatibility>>, because SE-0169 is also a source breaking
change, and the problem of access modifiers is important enough to relax
the rule of source compatibility for it, *especially if this is the last
chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private
Access Levels) which also has impact on source compatibility(given it
suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we
need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations
and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   https://github.com/apple/swift-evolution/blob/master/prop
osals/0169-improve-interaction-between-private-declarations-
and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       GitHub - apple/swift-evolution: This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
proposals/0169-improve-interaction-between-private-declarati
ons-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/mast
er/process.md#what-goes-into-a-review-1>What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

I’m more interested in practicality than appeals to authority. If no one is actually using extensions in this way, then we don’t need it.

Charles

···

On Apr 6, 2017, at 7:48 PM, Xiaodi Wu <xiaodi.wu@gmail.com> wrote:

On Thu, Apr 6, 2017 at 7:38 PM, Charles Srstka <cocoadev@charlessoft.com <mailto:cocoadev@charlessoft.com>> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

Presumably, proponents of SE-0025. That is, after all, an explicit part of that design, reviewed and approved by the Swift community and core team.

This use case has at least been brought up in discussions within my team. I wouldn't be surprised if it's actually deployed as well. Given a big project with enough experienced devs, I'd say this pattern is almost a certainty.

Daniel Duan

···

Sent from my iPhone

On Apr 6, 2017, at 6:53 PM, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org> wrote:

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

Me.

Even though I think we were better off without scoped `private`, I *have* used it fruitfully on several occasions. These were typically in places where I wanted to restrict access to a small number of members which I could ensure would enforce certain invariants. An example I gave previously involved two arrays which contained matching elements; code should never insert or remove from one array without doing the same to the other. By making these arrays `private` and exposing `fileprivate` and `public` members derived from them, I could ensure that only a couple dozen lines could possibly contain such a bug without changing the external design of the type or introducing boilerplate.

This proposal does not offer the same utility. The only way to protect fragile parts of a type from other parts is to extract them into a separate type, and even then, you can extend that new type anywhere in the file to access the fragile parts. You're also likely to end up having members on the outer type which simply call into equivalent members on the inner type. It increases boilerplate and reduces protection.

Despite having used scoped `private` in the past, if the choice were between keeping it and giving it `fileprivate` semantics, I would still support the latter; I think the simplification would be worth the loss of tight encapsulation. But this proposal offers *neither* simplification *nor* tight encapsulation, so I'm opposed to it.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

For the reasons I outlined previously, a very strong -1 as well.

I thought it was worthwhile to consider if the Swift 2 design was superior
to the Swift 3 design, but I feel very strongly that there should not be a
Swift 4 "private" that's different from both Swift 3 and 2.

···

On Thu, Apr 6, 2017 at 18:25 Slava Pestov via swift-evolution < swift-evolution@swift.org> wrote:

Strong -1. This is a source breaking change, but Swift 4 stage 2 is
already over.

Slava

On Apr 6, 2017, at 4:10 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations
and Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the
review manager. When replying, please try to keep the proposal link at the
top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reply text

Other replies

<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What
goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

   - What is your evaluation of the proposal?
   - Is the problem being addressed significant enough to warrant a
   change to Swift?
   - Does this proposal fit well with the feel and direction of Swift?
   - If you have used other languages or libraries with a similar
   feature, how do you feel that this proposal compares to those?
   - How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager
_______________________________________________

swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

Charles

On many occasions. If you have an extension that is a UITableViewDataSource, you may want private methods that prepare the cell, etc. Maybe not the most convincing example, but yes, there are such cases.

···

On Apr 7, 2017, at 2:38 AM, Charles Srstka via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Strong -1. This is a source breaking change, but Swift 4 stage 2 is already over.

Considering the importance of access control for a lot of people and the rare chance to do something about it, that looks a bit like a technicality Slava, no offence meant :)

···

Sent from my iPhone

On 7 Apr 2017, at 00:25, Slava Pestov via swift-evolution <swift-evolution@swift.org> wrote:

Slava

On Apr 6, 2017, at 4:10 PM, Douglas Gregor <dgregor@apple.com> wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and Extensions" begins now and runs through April 11, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
Reply text
Other replies
What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution-announce mailing list
swift-evolution-announce@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution-announce

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

We should evaluate the proposal in terms of what it can do not in "we are upset we are not getting that old proposal reverted" or "I want something else which I know I am not going to get".

Sorry if this is a bit direct, meant no offence.

···

Sent from my iPhone

On 7 Apr 2017, at 01:05, Vladimir.S via swift-evolution <swift-evolution@swift.org> wrote:

If you don't want to resolve the mistake of SE-0025 by proposing a really solution but not a workaround, then just leave the things where they are currently. Proposed "improvement" IMO is more confusing than helping.

Sorry, I don't buy <<..most of those proposals are not in scope for discussion in Swift 4 (or any later release), given the significant impact on source compatibility>>, because SE-0169 is also a source breaking change, and the problem of access modifiers is important enough to relax the rule of source compatibility for it, *especially if this is the last chance*.
Also, it seems like core team was ready to accept SE-0159(Fix Private Access Levels) which also has impact on source compatibility(given it suggested to remove scoped-private).
IMO SE-0159 + new 'scoped' keyword for scoped-private is the solution we need.

So, -1 from me.

On 07.04.2017 2:10, Douglas Gregor via swift-evolution wrote:
Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and
Extensions" begins now and runs through April 11, 2017. The proposal is
available here:

   https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

Reviews are an important part of the Swift evolution process. All reviews
should be sent to the swift-evolution mailing list at

   https://lists.swift.org/mailman/listinfo/swift-evolution

or, if you would like to keep your feedback private, directly to the review
manager. When replying, please try to keep the proposal link at the top of
the message:

   Proposal link:

       https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md

   Reply text

       Other replies

         <https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What
         goes into a review?

The goal of the review process is to improve the proposal under review
through constructive criticism and, eventually, determine the direction of
Swift. When writing your review, here are some questions you might want to
answer in your review:

* What is your evaluation of the proposal?
* Is the problem being addressed significant enough to warrant a change
   to Swift?
* Does this proposal fit well with the feel and direction of Swift?
* If you have used other languages or libraries with a similar feature,
   how do you feel that this proposal compares to those?
* How much effort did you put into your review? A glance, a quick
   reading, or an in-depth study?

More information about the Swift evolution process is available at

   https://github.com/apple/swift-evolution/blob/master/process.md

Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

`private` works for extensions exactly how the authors of SE-0025 intended it to do. Your comments do not address what would happen for those people who are making use of this functionality currently to isolate methods to the extension only.

Who is currently doing that?

Me.

Even though I think we were better off without scoped `private`, I *have* used it fruitfully on several occasions. These were typically in places where I wanted to restrict access to a small number of members which I could ensure would enforce certain invariants. An example I gave previously involved two arrays which contained matching elements; code should never insert or remove from one array without doing the same to the other. By making these arrays `private` and exposing `fileprivate` and `public` members derived from them, I could ensure that only a couple dozen lines could possibly contain such a bug without changing the external design of the type or introducing boilerplate.

This proposal does not offer the same utility. The only way to protect fragile parts of a type from other parts is to extract them into a separate type, and even then, you can extend that new type anywhere in the file to access the fragile parts. You're also likely to end up having members on the outer type which simply call into equivalent members on the inner type. It increases boilerplate and reduces protection.

What about using 2 files ? One for private fragile part, one for ‘public’ part.

···

Le 7 avr. 2017 à 03:53, Brent Royal-Gordon via swift-evolution <swift-evolution@swift.org> a écrit :

On Apr 6, 2017, at 5:38 PM, Charles Srstka via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

On Apr 6, 2017, at 7:34 PM, Xiaodi Wu via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Despite having used scoped `private` in the past, if the choice were between keeping it and giving it `fileprivate` semantics, I would still support the latter; I think the simplification would be worth the loss of tight encapsulation. But this proposal offers *neither* simplification *nor* tight encapsulation, so I'm opposed to it.

--
Brent Royal-Gordon
Architechies

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

-1 for reasons I've previously expressed in the discussions:

- It encourages everything to be stuffed in one file.
- It doesn't actually solve anything as the new private is very close to fileprivate, while abolishing private as truly scoped - which is a tool I use on regular basis.

Simply as long as it's file-based, it's not a solution, it's just another attempt to satisfy some part of the community. I'm not saying that the current access levels are perfect, but I still believe the way to go is to either use submodules, and/or introducing the concept of "protected" members.

+1 to the proposal.

How will submodules discourage stuffing everything into one file?
I can only think of creating a submodule per each class which doesn't look like a good solution.

I think this proposal is a step in the right direction. 'private' becomes type-based
and the only thing left to do is extending it to extensions in the module in the future.

Andrey

···

On 7 Apr 2017, at 07:57, Charlie Monroe via swift-evolution <swift-evolution@swift.org> wrote:

On Apr 7, 2017, at 1:10 AM, Douglas Gregor via swift-evolution <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:

Hello Swift community,

The review of SE-0169 "Improve Interaction Between private Declarations and Extensions" begins now and runs through April 11, 2017. The proposal is available here:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
Reviews are an important part of the Swift evolution process. All reviews should be sent to the swift-evolution mailing list at

https://lists.swift.org/mailman/listinfo/swift-evolution
or, if you would like to keep your feedback private, directly to the review manager. When replying, please try to keep the proposal link at the top of the message:

Proposal link:

https://github.com/apple/swift-evolution/blob/master/proposals/0169-improve-interaction-between-private-declarations-and-extensions.md
Reply text
Other replies
<https://github.com/apple/swift-evolution/blob/master/process.md#what-goes-into-a-review-1&gt;What goes into a review?

The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When writing your review, here are some questions you might want to answer in your review:

What is your evaluation of the proposal?
Is the problem being addressed significant enough to warrant a change to Swift?
Does this proposal fit well with the feel and direction of Swift?
If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
More information about the Swift evolution process is available at

https://github.com/apple/swift-evolution/blob/master/process.md
Thank you,

-Doug

Review Manager

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org <mailto:swift-evolution@swift.org>
https://lists.swift.org/mailman/listinfo/swift-evolution

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

What is your evaluation of the proposal?

Strong -1. Just rename ‘fileprivate’ to be less annoying.

So, we keep being told it won't happen and our current Bly suggestion discussing this proposal cannot be to just keep asking for it, can it?

···

Sent from my iPhone

On 7 Apr 2017, at 09:56, Jonathan Hull via swift-evolution <swift-evolution@swift.org> wrote:

This proposal will make things even worse than they are currently. We will regret it just as much, if not more than, 0025. As others have mentioned, it is actively harmful:
• It once again changes the meaning of private
• It takes away most of the actual power of private (vs fileprivate). (I was for returning to the simpler Swift 2 access, but when I did use private, I used it to limit access to just a few lines of code. This proposal gets rid of the last ounce of usefulness of ‘private’ for me, and only has the virtue of a less annoying name).
• It is the camel’s nose in the tent for type-based access (people will ask for future versions to be available in the type in the submodule, module, and then public… but we will be unable to give it to them)
• It breaks the same code that 0159 would have broken
• It will be a nightmare to teach/learn

Also, the idea that we should limit the use of ‘fileprivate’ is incorrect. Fileprivate is the best access levels for a lot of cases, it just has an annoying name. Given our constraints, I now believe the only sane choice left to us is to make fileprivate easier to use (as opposed to making private more like it) and to get rid of the cognitive dissonance of having similar names/concepts by renaming ‘fileprivate’ to something like ‘local’. ‘fileprivate’ (whatever it is called) should be the soft-default. ‘private’ should be the one being used explicitly.

We are likely going to have to rename ‘fileprivate’ anyway to work with submodules (that or add another access level), and ‘local’ has connotations of visible nearby… so I think it works well enough.

Is the problem being addressed significant enough to warrant a change to Swift?

Yes, access controls are a mess… but this will make them more of a mess.

Does this proposal fit well with the feel and direction of Swift?

No.

If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?

No. I have used languages with type-based private, and I have used languages with file-based private… but never type-based that was limited to a file. You got shrimp in my chocolate (not all great tastes go well together).

How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

I have followed the discussion closely and spent a great deal of time thinking about it.

Thanks,
Jon

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

This is the base of your argument, and I think it is wrong, considering that code is a living matter, not a static one.

Too many properties initially declared as `private` have to be declared `fileprivate` later, because the code is evolving. And this change is usually performed just to tame a compiler error.

This is why the current private/fileprivate situation is actually a semantics problem. Private is not stable enough to mean anything.

Gwendal Roué

···

Le 7 avr. 2017 à 13:44, Matthew Johnson via swift-evolution <swift-evolution@swift.org> a écrit :

No. I believe it makes the language worse, not better. It doesn’t address the real problems with access control. The largest problem is the inability to form scopes between files and the entire module. The problem with `fileprivate` and `private` is a naming problem, not a semantics problem.