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

[T.J. Usiyan]

   - What is your evaluation of the proposal?

+ 1

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

Yes

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

I'm not completely sure.

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

Mixed. I won't get into all of the things I wish it did or did not have.

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

I've followed the discussions and read the proposals.

Overall, I don't think that this is necessarily ideal but I do believe that
it would be a net positive for the reasons stated. `private` would become
more common and `fileprivate` less.

On Mon, Apr 17, 2017 at 4:23 PM, Riley Testut via swift-evolution <
swift-evolution at swift.org> wrote:

> I think its important to point out that its more than aesthetics: because
> the simple file and extensions scenario are so common, it forces us to use
> both private and fileprivate fairly regularly, which increases the total
> number of access control to work with on a daily basis. And I think that’s
> the important point. That’s why open is a success IMHO: because it only
> needs to be used rarely, it provided the required functionality without
> increasing the number of access modifiers that needed to be used regularly.
>
>
> I agree 100%. I’ve never been a fan of open, and still disagree with the
> rationale for why it was added. However, because it does follow Swift’s
> progressive disclosure emphasis, and because it does accomplish what it was
> designed to do, I’ve made peace with it.
>
> Fileprivate is different. It was intended to be used rarely, as another
> form of progressive disclosure, and when it *was* used, it had meaning.
> However, as has been discussed many times, this is not the case.
> Fileprivate, for a multitude of reasons, is used far more frequently than
> anticipated (fileprivate is certainly used way more than private in my own
> projects), and as a result *loses *its meaning. When looking at a
> fileprivate declaration, there is no way to know whether it is intended to
> be exposed to separate types, or simply to extensions of the same type.
>
> Again, I personally think access control was far simpler in Swift 2.
> However, because the idea of scoped access clearly has value to many
> developers, I am okay with adding that functionality to the language. By
> allowing extensions to access private variables, fileprivate has actual
> meaning again (which was the original intention) and is also something that
> many developers may never need to use.
>
> FWIW, I really don’t view this proposal as just a stop-gap, I think
> accepting this proposal will genuinely be the *best* option for Swift in
> general. I personally don’t like the idea of renaming private to scoped,
> since I think private and fileprivate are better terms in general. I just
> want private member access in my extensions for God’s sake :^)
>
> On Apr 17, 2017, at 1:08 PM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> I think its important to point out that its more than aesthetics: because
> the simple file and extensions scenario are so common, it forces us to use
> both private and fileprivate fairly regularly, which increases the total
> number of access control to work with on a daily basis. And I think that’s
> the important point. That’s why open is a success IMHO: because it only
> needs to be used rarely, it provided the required functionality without
> increasing the number of access modifiers that needed to be used regularly.
>
>
>
> _______________________________________________
> 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/20170417/c9eb2ce5/attachment.html>