SE-0450: Package traits

[allevato (Tony Allevato)]

Logistical request: Can you please add a link to the original pitch thread to the proposal header? I wanted to reference some of the original discussion and had to search the forums to find it.

Overall, the requirements that traits be purely additive eases many of the concerns I had about build scalability. I still disagree with the idea presented in the original pitch thread that it's more desirable to use traits to control, for example, whether different data structures in Collections are compiled as part of the same module as opposed to just putting them in separate modules and letting users depend on the precise ones they want. But, that's mainly a criticism of specific proposed uses of traits and not of the overall feature, which has other valid uses.

Regarding the proposal itself:

There seems to be an inconsistency in the write-up about allowed characters in names of traits. It claims that they must be valid Swift identifiers, but then goes on to list possibilities that aren't valid Swift identifiers:

Allowed characters for trait names

Since traits can show up both in the Package.swift and in source code when checking if a trait is enabled, the allowed characters for a trait name are restricted to legal Swift identifier. Hence, the following rules are enforced on trait names:

• The first character must be a Unicode XID start character (most letters), a digit, or _.
• Subsequent characters must be a Unicode XID continue character (a digit, _, or most letters), -, or +.
• default and defaults (in any letter casing combination) are not allowed as trait names to avoid confusion with default traits.

These rules would allow for trait names like 1foo, hello-there, and foo+bar. If these traits are getting passed to the compiler as simple -D flags so that they can be checked in #if blocks, how is a user expected to test for any of those which aren't valid Swift identifiers?

Trait names are namespaced per package; hence, multiple packages can define the same trait names. Moreover, it is an expected scenario that multiple packages define the same trait name and conditionally enable the equivalent named trait in their dependencies.

Just to make sure I'm on the right page:

A module can write #if TraitName to check internally if a trait is enabled, to control the presence of some API or logic (because the module is compiled with -DTraitName).

Do these propagate up the build graph? Can someone who depends on that package/target also write #if TraitName to control whether something is conditionally done based on whether they've requested that trait for the dependency? I assume the answer is no, because (1) it's not necessary, the author of that code knows whether they've enabled the trait or not on the dependency, and (2) it means that the traits would not actually be namespaced per package as described above.

Is my understanding correct?