The original thread on this wound up turning into being able to mark certain dependencies as platform-specific, but as far as I can tell, there's still no way for me to say within the same library that a core target should be available on all platforms, while secondary target b is only available on macOS/iOS etc but not for Linux.
This is frustrating since one may not want to expose all related targets of a single library to all platforms, and you have to #if out a ton of stuff in targets that are not meant to support all platforms, even if the case is that you want literally none of that specific target to be available on that platform.
Is adding a platforms property to Target still a possibility? What are the complexities I'm missing in doing that?
I don't think it would be a good idea to add fine grained platform restrictions before we even have a way to do this in a coarse grained way at the package level.
During the review of SE-0236, we couldn't come up with a design for coarse grained restrictions that was generally accepted. In my mind, we should revisit that first and come up with a design for restrictions at the package-level that makes sense. Once we have that, we can think about whether it could be beneficial to have a per-target configuration that uses the same semantics.
I'm a bit confused - how does the platforms property at the Package level not constitute those coarse-grained restrictions? Is that the bit in future directions about preventing usage?
Let me know what I can do to help with this - I have idea of how this works under the hood but I can at least write up the bit of the proposal that's "what we want it do do"
platforms should really be named minimumPlatformVersions. The lack of a plaform in the platforms array does not mean that the platform is unsupported, it only means that such platform does not have a minimum version requirement to build.
AFAIR this confusing name is kept to preserve backwards compatibility, or because we haven't found a good way to migrate away from it moving forward.
If you want to propose something here, I would recommend revisiting this review thread to make sure your approach addresses the various concerns about introducing platform restrictions.
It does look like that came close to a solution here with @Aciid's suggestion of adding a restricted: true parameter that would indicate that unless something is specifically enumerated or not known by the current tools version, it is not supported.
However, it didn't land in the final version of the proposal, and it's not addressed in SE-236 or in that thread why it wasn't. Is there any clarifying information you can share as to why, or was it just too late in the discussion?
idea of how this works under the hood but I can at least write up the bit of the proposal that's "what we want it do do" 