[swift-evolution] access control

Thorsten Seitz tseitz42 at icloud.com
Wed Jan 27 10:22:09 CST 2016

Ah, of course, you are right. Mixing both levels (file and class private) isn't possible with the current model, it's either one or the other.

Feeling a bit silly for not thinking of that myself and apologies to Ilya and you all for being a little thick-headed...


> Am 26.01.2016 um 05:40 schrieb Rob Mayoff via swift-evolution <swift-evolution at swift.org>:
> On Mon, Jan 25, 2016 at 10:37 PM, Nate Birkholz via swift-evolution <swift-evolution at swift.org> wrote:
> >> Note that moving a private class to its own file to make its privates more private does not work. Now I have to make the formerly-private class an internal class, so I'm not sending the first message anymore.
> >
> > Why do you have to make it internal then? I'm confused.
> In Scheduler.swift, I have public (or internal) class Scheduler, and it uses private class JobRecord, also in Scheduler.swift.
> I want to make some of JobRecord's members private to JobRecord. Right now, the only way to do that is to move JobRecord to a separate file, say JobRecord.swift, so that its privates become "more private" (since class JobRecord is the only thing in JobRecord.swift).
> But in order for JobRecord to be visible to Scheduler, I now have to change "private class JobRecord" to "internal class JobRecord". The message-to-future-Rob that JobRecord is only intended for use by Scheduler.swift is lost (or at any rate its accuracy is no longer enforced by the compiler).
> _______________________________________________
> 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/20160127/9df28d0a/attachment.html>

More information about the swift-evolution mailing list