I went through the proposal text, and sorrily didn’t see package’s advantage over SPI except for a shorter syntax. Most “bonus”es from the pitch can simply apply 1:1 to the SPI world.
The biggest problem of this pitch, IMO, is that it assumes an arbitrary package context for Swift codes, which is absolutely wrong because there’re plenty of Swift codes in the form of standalone script files, CMake(-compatible) projects, Xcode projects, standalone XCTest suites, etc. All of them are not necessarily (for some, almost never) “package”s. I really don’t like the idea of “introducing a keyword in the Swift language, but for SwiftPM packages only”.
What somehow makes things worse is, as @8675309 has pointed out, splitting giant packages (projects) is a best practice in software engineering, but this pitch makes it way harder to do that while SPI just works smoothly.
Below are some other nits of the proposal, which just didn’t change the overall -1 I would give:
- After this pitch, the “exported interface” is divided into two layers:
publicandpackage, which could have different module dependencies. That means in order to maintain thepackage-level interface, a target may rely on (and even accidentally expose!) some modules that are totally unused inpublicAPIs, and vice versa. - Also, try to consider “qualified imports” — what if we want to explicitly import only
publicAPIs inside the package for some purpose (eg. providing an example/template target for users)?