[swift-evolution] SE-0025: Scoped Access Level, next steps
jordan_rose at apple.com
Wed Mar 30 17:28:51 CDT 2016
> On Mar 30, 2016, at 15:20, Brent Royal-Gordon <brent at architechies.com> wrote:
>> Now, it is a very useful feature! Apple, of course, does this all the time with its "SPI". But I think the right form of the feature is to be able to tag a bunch of public declarations as "SPI" or "limited" or "limited to group 'X'" or possibly even "limited to module 'X'", and then have a tool to strip them out of the swiftmodule file when you're ready to ship this module to people. That way you're enforcing your limitations as much as possible, while still using the same binaries for both internal and external clients. (Remember that the swiftmodule file serves essentially the same purpose as header files in C.)
> Actually, I can think of one very interesting boundary that roughly parallels the SPI/API boundary: the boundary between resilience domains. In other words, "public within resilience domain" may be a useful access level.
> However, that obviously is not the same as exposing to different modules. I understand why you might not think that's a good idea.
Hm. That may indeed be useful because it allows the compiler to omit resilient information about the declaration. I'm worried that's just adding more knobs that won't really be a benefit in practice, though.
(For anyone wondering what this is, it's part of the very long design document for future "Library Evolution Support in Swift <http://jrose-apple.github.io/swift-library-evolution/>".)
>> At the file level, there's nothing inherently wrong with this idea, but I don't think there's enough gain to writing file strings directly in source files. Pointing to a future "comprehensive submodules model" would be disingenuous because that's a huge feature with a lot of subtlety, but I think "just make this accessible to one other file" is additional complexity for not much gain. It's also subject to slippery-slope: once one file is added, I don't think anyone would think too hard about adding a second file, and then…
> It does offer a solution to the stored property problem (because you can only define stored properties in the type's main definition, all stored properties must be able to see each others' private state); you could put each extension in a separate file and then expose the relevant stored properties only to the file for the extension that needs it. But I do understand why you might not like that idea; there is a certain smell associated with embedding source file names in your code.
> Mostly, it just bothers me that we have these two middle access levels (`moduleprivate` and `fileprivate`) which seem closely related compared to new-`private`, yet are both completely ad-hoc and elude decent naming. Calling them, say, `internal` and having `internal(#file)` be a special case of `internal(file names here)` seems like a nice way to rationalize them.
Can you elaborate on why "moduleprivate" and "fileprivate" are closely related for you? To me all three of the proposed non-public levels are "concentric circles"; one of them is bounded by braces, one by the filesystem, and one by the files in your target (as described by Xcode or the package manager or an ad hoc build).
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution