[swift-evolution] Type-based ‘private’ access within a file
Charles Srstka
cocoadev at charlessoft.com
Wed Apr 5 18:19:41 CDT 2017
> On Apr 5, 2017, at 6:10 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org> wrote:
>
>> On Apr 5, 2017, at 2:27 PM, Tony Arnold via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>
>> I know Swift has different purposes for different people here, but ultimately it’s supposed to support great application development for Apple’s platforms, right? To my eyes, `fileprivate` should never have been introduced without some kind of `typeprivate` (similar to how things would be declared back in Objective-C land with a `*+Private.h` header that you could import when it was needed). Right now, there’s no way to duplicate that pattern in Swift - I would need to make anything I wish to access `internal` which exposes it to everything within the application/module - surprisingly, this is a regression from the tooling and access levels I had available in Objective-C.
>
>
> If our goal was to duplicate what Objective-C could do but without header files, we would essentially have:
>
> * `public`
> * `internal`
> * `semiprivate`
> * `fileprivate`
>
> Symbols in `semiprivate` scope would be visible to the file they were in as well as any file that explicitly asked for access to `semiprivate` symbols in that file. (In practice, I think we'd probably tie `semiprivate` to submodules, not to files, though submodule membership might not have a granularity below full files.)
>
> There would be no scoped `private` or `typeprivate` or anything of the sort. That just isn't a thing that existed in Objective-C. So I'm not sure why you're invoking Objective-C to argue that we need a type-based private.
Because while it was technically possible for any file that wanted to to include the private header, in *practice* this was often used to implement ‘typeprivate’-like functionality.
Charles
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170405/29ee660b/attachment.html>
More information about the swift-evolution
mailing list