[swift-evolution] Type-based ‘private’ access within a file

Xiaodi Wu xiaodi.wu at gmail.com
Mon Apr 3 15:01:25 CDT 2017


I'm disappointed in this turn of events. While I thought that accepting
SE-0159 would have been a better outcome than rejecting it, I am certain
that this is an inferior choice to both of those outcomes.

The key problem isn't principally _what_ this proposed private is. It is
that, if adopted, this would be the third flavor of private in as many
years. It is a new design with its own kinks (what to do about `private
extension`, for example?) and the resultant churn would be most unfortunate.
On Mon, Apr 3, 2017 at 14:50 David Hart via swift-evolution <
swift-evolution at swift.org> wrote:

> The problem I see with that is that it would introduce orthogonal access
> levels whereas they have all been hierarchal in nature up to now.
>
> On 3 Apr 2017, at 21:36, Charles Srstka <cocoadev at charlessoft.com> wrote:
>
> On Apr 3, 2017, at 2:28 PM, David Hart via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> Btw, I know what I'm going to propose is a bit crazy, but how about making
> private visible to extensions even outside the file but in the same module?
>
>
> That’s actually what I suggested in my original post on the topic. My
> feeling was that it would allow breaking a particularly large type into
> separate files, thus alleviating the “huge file” problem that Swift has
> (and which Charlie Monroe brought up as a concern).
>
> It’s still what I’d prefer personally, although I can understand why the
> core team might want to restrict it to files.
>
> Charles
>
>
> _______________________________________________
> 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/20170403/923fa3d6/attachment.html>


More information about the swift-evolution mailing list