It's sufficient in the current implementation. For module name completion (after import), we hide all modules starting with _.
1 Like
My apologies if I missed it in my reading but is there a rationale for not 'just' explicitly stating the dependencies in the json file and then generate an underscored name? This might be a complete non-issue but it makes more sense to me somehow.
{
"version": 1,
"parents": [ // absolutely no strong feelings about the name of this key
{"name": "NumericKit"},
{"name", "FormatKit"}
]
}
This functionality would be very, very welcome.
Our existing (single-module) overlays are shipping as regular standalone dylib targets (not frameworks). Discovery is done through a naming scheme, with no requirement for explicit registration. Is there a specific reason to define these cross-cutting overlays as full frameworks, or was that just a non-normative example? (Our existing single-module overlays are standalone dylibs, not frameworks.)
+1. I think we should have a strictly enforced naming scheme for such overlay modules.
Followup: why not just do away with JSON descriptors entirely, and figure out what cross-cutting overlays need to be loaded based on their name/location, like we do for regular overlays? (There is a combinatorial explosion, but only if we don't have a complete list of all such overlays. Admittedly I have no idea if building such a list is feasible.)
That does seem nicer but one problem with that is now the compiler (and any other tool that looks at the JSON file) now needs to know how to compute the name of the cross-import overlays from the names of the parents. In terms of amount of implementation work, it is not that much, but it seems an unnecessary addition; now the naming scheme is part of the Swift language instead of being a convention.
I suppose it is a matter of opinion whether that is a big deal or not. Other things being equal, I would prefer that we not wire more of these little details into the compiler. If that helped out users in a major way, that would change the equation but I don't think this qualifies.
But yeah, since this is a small detail, I can change it if other people feel the same way. 
I actually think that the language holding it is an advantage but I admit that it is mostly my feeling. A stable order/naming that Swift managed seems like the best option to me.
I think it would be important to be able to look at a .swiftmodule and understand from a glance that it is supposed to be a combo overlay, not a standalone module. Enforcing consistent naming is a good way to ensure that.
The problem with allowing people to customize the cross-import module name is, of course, that people will then go ahead and customize the module name.
Is there a specific reason to define these cross-cutting overlays as full frameworks, or was that just a non-normative example?
The idea behind making them a full framework is that the author can avail of the flexibility of frameworks. For example, if you want to have some data files/assets associated with the overlay, it might make more sense to use a framework compared to embedding those assets in the dylib itself.
Followup: why not just do away with JSON descriptors entirely, and figure out what cross-cutting overlays need to be loaded based on their name/location, like we do for regular overlays? (There is a combinatorial explosion, but only if we don't have a complete list of all such overlays. Admittedly I have no idea if building such a list is feasible.)
The problem with building such a list is that it is bad from a caching perspective. Adding a single module anywhere along any search path invalidates the cache, which is quite pessimistic. We already have this problem today in the form of -I today... having this kind of lookup would make the problem worse.
3 Likes
What's the status of this? I saw it mentioned in the thread on What's New for Foundation, but it seems like this is not yet implemented? Did a Swift Evolution proposal get put together?
1 Like