[swift-evolution] SE-0025: Scoped Access Level, next steps

[Brent Royal-Gordon]

> 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.

> 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.

-- 
Brent Royal-Gordon
Architechies