> 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 _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
