[swift-evolution] private & fileprivate
xiaodi.wu at gmail.com
Fri Oct 7 21:37:40 CDT 2016
On Fri, Oct 7, 2016 at 8:49 PM, Braeden Profile via swift-evolution <
swift-evolution at swift.org> wrote:
> > On Oct 7, 2016, at 5:46 PM, Trans via swift-evolution <
> swift-evolution at swift.org> wrote:
> > Private access that limits exposure to extensions and subclasses is
> > the bane of reusability. It sucks in Java and it sucks in Swift. As
> > far as I know Ruby is the only language that seems to get that.
> Agreed. Reading this thread, almost everyone’s presented actual use cases
> would be fixed if we could do something functionally equivalent to
> private(type) (even if that’s not the best syntax). If we could have the
> ability to write extensions for a type throughout a module and access its
> private properties (and private subtypes, methods, etc.), then the ugliness
> introduced by fileprivate would be all but eliminated. That’s an access
> level I would love.
> I do want to mention, though, that while I would enjoy C++-style
> type-level private, I don’t want protected. The rationale for avoiding
> that in Swift is fantastic.
If I recall correctly, this idea was also put forward during the original
SE-0025 discussions. However, the design we have now was chosen over this
alternative and others. I was one of those people who didn't really like
the new private, didn't like `fileprivate`, and generally felt that
alternative designs (or even the Swift 2 status quo) could be superior.
But, the discussion was had, all of these viewpoints and more were aired
and mulled over, and a consensus was reached. It'd have to be some
startling new insight to justify yet another change for Swift 4.
> > swift-evolution mailing list
> > swift-evolution at swift.org
> > https://lists.swift.org/mailman/listinfo/swift-evolution
> swift-evolution mailing list
> swift-evolution at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution