I am strongly opposed to Swift inventing entirely novel terms for this. If we consider this to be an "API" for cross-compilation, then we should embrace the philosophies of the Swift API Design Guidelines:
- Don’t surprise an expert: anyone already familiar with the term will be surprised and probably angered if we appear to have invented a new meaning for it.
- Don’t confuse a beginner: anyone trying to learn the term is likely to do a web search and find its traditional meaning.
- Embrace precedent. Don’t optimize terms for the total beginner at the expense of conformance to existing culture.
Inventing new names fails all three of these checks.
It could be argued that "precedent" here is fuzzy because different build systems have done different things. Even in that case, inventing a whole new standard isn't the right answer. We need to break the tie, and the best way to do that is to acknowledge that Swift is an LLVM- and Clang-based toolchain and that the least confusing option is to adopt the same terminology used by the compiler's underlying technology. That's "host" for the platform where the compiler runs and "target" for the platform where the compiled code will run.
I don't find the argument about target being confusable between a SwiftPM target and a target triple to be compelling for a few reasons:
First, every build system I've interacted with in my career uses "target" to refer to a library or binary that can be built. Almost every build system I've interacted with refers to a "target platform/configuration/environment" as well. These are used in completely different contexts and rarely confused by users.
This is an "expert"-level feature, for some definition of "expert". That is, it is not something your average day-one Swift developer is going to stumble on. I think it's fair that folks doing cross-compilation should be expected to have a deep enough understanding of their environment that they aren't confused by target in the context of a platform and target in the context of a thing being built. If we invent entirely new terms, they will immediately be less discoverable than using existing terms of art, and users of this feature who are used to other tools will be confused about why the terms don't align. This is especially true if they are doing advanced stuff with Clang and have to switch between different terms in the same build.
Lastly, I would expect triple: .target to be the default configuration for a SwiftPM target, and users would only need to specify that argument when they want to reference the host (or some other future alternative platforms).
IMO, the misnamed thing here in SwiftPM's existing target(...), which should be named something like module(...) instead. target in this usage is too vague, given that there are also executableTargets and testTargets—there's nothing that explains to users what a plain old target is. That's out of scope for this proposal, but given that SwiftPM maintainers have expressed a desire to move away from the target suffix, maybe there's a future where target itself is renamed as well, and then we have no need to worry about a conflict with the target triple.