> On Apr 5, 2017, at 2:27 PM, Tony Arnold via swift-evolution > <swift-evolution@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. -- Brent Royal-Gordon Architechies
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
