Thank you for putting thought into this.
I tend to agree with @Aciid that the general ideas of your proposal and your core principles of type safety and folderābased types are good (and I kind of doubt anyone would disagree with that). But I also agree with him that it does not all need to be part of the initial proposal.
Thank you for insisting on generated constants though. I realize you probably already read it, but I am worried about the alternative dynamic stringābased access causing issues with future optimization.
The one part I donāt quite understand is the benefit to having resources in separate targets.
If they are within the same target as related source, then access control works as normal. They can default to internal and for the time being can be made public when desired by forwarding:
extension UIImage {
public var coolImageForOthersToUse: NSImage {
return MyResources.coolImage // internal
}
}
Some future proposal might add a way elevate them to public automatically instead, but it isnāt immediately necessary. (I have no objection to such a future, but thinking about it now, I would probably use forwarding instead even if that future arrived, since having generated code in the public API seems like a headache for version compatibility. Forwarding allows (1) that it be exposed somewhere more intuitive in the API and (2) that the implementation is open to changing to something dynamically constructed without affecting the API.)
However, if the resources live in a separate target, then they have to be public and cannot be restricted to a particular target. (That has implications for incremental builds, and at the moment it also means clients can access every resource, since the package manager doesnāt gate import statements according to whether they are actually exposed in a product or not.)
I am not very strongly opposed to this direction though (partly I am just already accustomed to the other way), so if you have a good reason, please share it.