> On Apr 5, 2017, at 6:10 PM, Brent Royal-Gordon via swift-evolution > <[email protected]> wrote: > >> On Apr 5, 2017, at 2:27 PM, Tony Arnold via swift-evolution >> <[email protected] <mailto:[email protected]>> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
