[Accepted] Vision: Swift Platform Support: A Vision for Evolution

Evolution Announcements
1

Hi folks,

I'm pleased to announce that the Platform Steering Group has today published its work on platform support, titled Swift Platform Support: A Vision for Evolution.

The Swift programming language has evolved into a versatile and powerful tool
for developers across a wide range of platforms. As the ecosystem continues to
grow, it is essential to establish a clear and forward-looking vision for
platform support. This vision has two main goals:

  1. To establish common terminology and definitions for platform support.

  2. To document a process for platforms to become officially supported in Swift.

The document, co-authored by members of the Platform Steering Group (notably @compnerd, who wrote the original draft), sets out the four different platform support tiers and defines the mechanism by which platform owners can request that their platform be included in a specific support tier.

Please feel free to continue discussing this vision document in this thread.

Alastair Houghton
Platform Steering Group

26 Likes
2

There might be some mis-editing, the vision document currently has two "Tier 1" sections.

3

That is intentional. The first one is Tier 1 (general), and the second is Tier 1 (for toolchain hosts). Perhaps we should have labelled it Tier 1a or something instead.

The point is that you don't need to be a toolchain host to be in Tier 1, but if you are, then some additional requirements apply.

3 Likes
4

Document is looking good, thanks for the well-reasoned guidance from @compnerd, @al45tair, and the PSG. :smiley:

Some thoughts:

  • This doesn't seem like a vision document, more about process, does it belong instead here on github or on swift.org?
  • Will each of the linux distros now get an owner? Seems like that would be worthwhile.
  • It would be nice if an explanation or link were added for what a SBOM or "provenance information to validate the software supply chain" consists of, so this doesn't have to be explained informally through other channels each time.
  • "Ensure that dependencies beyond the platform SDK can build from source" is a bit vague: these are general Swift packages, like the thousands found in the SPI, or specific dependencies of the SDK, like libcurl->FoundationNetworking for linux?
  • It is good that the grandfathering of current official platforms is explicitly stated, to forestall complaints that new platforms are unfairly being held to a higher standard otherwise.

The Android workgroup obviously plans to submit it through this process- we are unofficially somewhere between tiers 1 and 2 now- looking forward to other platforms like the BSDs being added too. :wink:

1 Like
5

Tier 1 toolchain is interesting. OpenBSD has some diverging features between the platform LLVM and the upstream LLVM such that the clang/lld requirements might be potentially problematic depending on how you read the document, but I don't anticipate OpenBSD getting to Tier 1 any time soon. Tier 2 (with swiftc+swiftpm) seems reasonable, however.

3 Likes
6

I feel like “if applicable” is doing a lot of heavy lifting in the case of Embedded-only platforms. Is it worth making the requirements for Embedded platforms an explicit subset of the requirements for non-Embedded? (easy for me to say, who will not be maintaining this policy)

7

Embedded is an interesting case. There are so many different embedded platforms, some of them private. I am investigating how SwiftPM can become more involved in the Swift Platform build and deployment process with the goal to enable third parties to add platforms on their own. We'll see what the fruits of that are but if we really want to reach Swift Everywhere, we need to make it easier for it to spread :slight_smile:.

5 Likes
8

Question for the folks who are more familiar with the moving parts of triples. The doc that @al45tair posted targets are triples having up to eleven parts with them. I was recently re-reading swift-evolution/proposals/0387-cross-compilation-destinations.md at main · swiftlang/swift-evolution · GitHub which makes a reference to LLVM’s triple as it pertains to SDKs. (I’m researching to do some documentation work for the SwiftPM docs, which are currently light on anything to do with using an SDK).

Do LLVM triples also potentially have all those components as well? Or is there a different interpretation of a triple in use with LLVM that should be mapped in some way?

In particular, i’m trying to understand how to guide someone properly for invoking the SDK based on the identifier, which seems to (maybe by convention) overlap heavily with triples.

9

Yes, the triple in LLVM should be able to represent all those components. All of those triples are (at least when I last checked) properly processed by LLVM for the various attributes. This document is potentially the first one that covers them in more detail as to what pieces there are. The closest other source I can think of is the implementation of config.guess and config.sub which guess and canonicalise build triples.

Note that triples are not sufficiently canonical for this. Concretely, while possible to represent, there are some parsing ambiguities and place sub-optimal handling in clang. e.g., armv7-m_eb-unknown-linux-gnueabihf2.41-macho doesn't actually process the glibc version to actually optimize code generation for that version of libc. Additionally, this is not necessarily fully canonical, as I believe that gcc might still represent this as: armv7-m-unknown-linux-gnueabi, requiring additional flags such as -mbig-endian -mfloat-abi=hard and simply hardcode the object file format into the build. The ambiguity in this particular case is: is thumb code allowed or not? That is, should this be treated as -mno-thumb? IMO, the SDK selection should be a higher level operation controlled by the SDK vendor via description strings.

1 Like
10

I don't think it belongs in the docs folder, but it would be good perhaps to have some space somewhere on swift.org itself for this information, and also for the list of platforms, owners and tiers, so that's something we're looking at — but we wanted to get this published sooner rather than later, so for now it's in the form of a vision document.

Ownership of the existing platforms is something we need to talk to people about; one of the reasons we didn't publish the platform/owner/tier list at the same time is that there was some debate about who owned what. But yes, in principle, different Linux distributions might have their own distribution owner (which may be the same person in some cases).

I think it's intentionally vague — the point here is to make sure that we've got an implementation of Swift and not some sub-language that can't cope with anything other than what's in the SDK, rather than to stipulate exactly what needs to build. It is specifically not a requirement that e.g. every package on the Swift Package Index should build without errors.

I think for now I'd rather leave things as open as possible (and lean on "if applicable" as well as the notion that platforms may not need to strictly comply with every requirement to be in a tier, as long as there's a good reason for the non-compliance). My feeling is that we may codify more things in future as we develop experience with the process.

2 Likes
11

Hello :waving_hand:! Not to be polemical here, just trying to understand the reasoning. Beside the practicality of “demanding” it angle, how does the requirement that “all/most/% percent of the most popular packages that can be built and that do build for one platform do build for all platforms in the same “tier” (if we talk about support tiers) go against the idea of having one single Swift language and not a range of sub specs /variants of Swift? In other words how is not making that a requirement keeping Swift the same everywhere and able to cope with things outside the core SDK as you were saying?

12

I've read this a few times and I'm still not certain what you're asking.

I wonder if you're talking about

where I was really just saying that we don't expect every platform to be able to build every package; the requirement in the document is just that "dependencies beyond the platform SDK can build from source", but we don't specify what those dependencies are specifically. I would expect that a platform could build some subset of the packages in the Swift Package Index.

13

Is wasm/WASI a platform for these purposes?

It seems like the most well-defined of the embedded targets, and a growth vector for inter-op with web and nested code (i.e., for the other sense of embedded, where one runs code in an interpreter).

It would be nice if Swift changes had to consider wasm applicability and implementation before merge and release where possible (and thus for CI to incorporate it).

But it's less clear whether the people working on wasm want the additional burden of supporting it as a platform. The opportunity might attract others, but I trust the Platform Steering Group to only select stewards who show some enduring commitment and ability to maintain a productive sub-community.

14

This is may seem like a nit in this context, but I'm a little concerned about terminology of ownership. This is not that.

Possession implies the right to exclude others, and that monopoly can be franchised and thus bears investment. But in this case (unless the license changes), anyone will still be free to produce other implementations for the same target. If you induce reliance by people with expectations of ownership but cannot deliver the right to exclude, they could have a legal snit.

If you look at comparable efforts (apache, python, eclipse, CNCF, openjdk, ...) you'll see a lot more attention to governance and rights. Here for simplicity it should probably instead be made clear that these are just expectations set between members of the contributor community (which are neither promises nor enforceable).

As a practical matter, the vision affords developers the respect and essential convenience of expecting PR's to be tested and integrated into all supported platforms before being merged or at least released. But I would be reluctant to set expectations e.g., that an iOS release will necessarily be delayed by a Linux bug.

Instead of owner, the notion of steward works well enough to afford the requisite deference and organizational defaults to protect time/effort investments in the platform and reduce coordination costs. Contributors will work together in good will as suggested, and users are risk-averse enough to strongly prefer the official platform distributions. "Ownership", if it is used at all, simply refers to someone's taking responsibility for development efforts, and being afforded corresponding authority for coordinating such efforts.

1 Like
15

It is, and there is active work on the WebAssembly front (I'll let @Max_Desiatov speak more about that, though).

We already had the notion of a "platform owner" (for instance, @compnerd has long been the platform owner for the Windows platform support in Swift), so this terminology isn't new and we haven't really made an attempt to define it here. I think the reality is that a platform owner is more than a steward, but rather less than a "dictator-for-life" (ala Guido van Rossum in the case of the Python project). The way I see them, they are there to provide expertise and guidance on their platform for the rest of the Swift Project, and to help steer the support for their platform, in conjunction with the Platform Steering Group. Most of the rest of what they do flows from that.

And as you say, Swift is Open Source, and in principle anyone is free to fork it and do their own thing, subject to terms of the license agreement — though from a community perspective that is often counterproductive and is something I personally would usually discourage.

Quite, hence the wording at the end of the Tier 1 section where it says (emphasis mine)

  • New features should aim to function on all Tier 1 platforms, subject to the availability of appropriate supporting functionality on each platform.

  • There is a presumption that a release of Swift will be blocked if a Tier 1 platform is currently broken. This is not a hard and fast rule, and can be overridden if it is in the interests of the Swift project as a whole.

I think everyone appreciates that there might be cases where, for reasons of resource or timing, or because a feature is difficult or impossible on a particular platform, we may end up not meeting the goal of having all new features land on all supported platforms in any given time frame (or in some cases even at all). This is more a statement of intent; that we want Tier 1 platforms to have and maintain feature parity where possible, and that we want to try to ensure that when we do a release, we release builds for all Tier 1 platforms on our release date.

6 Likes
16

Thank you for your replies - agreed and understood, for my own case.

I agree completely that this is largely understood in the Swift community.

Let's just bear in mind that a vision document speaks also to those not in the community, seeking to enter it. Swift's cross-platform potential looks like an opportunity to some (e.g., today's forum post about embedding into python notebooks). This creates strong interest in securing such opportunities (ranging from one developer just wanting to make a name to a vast sea of investors funding contributors), resulting in a community at cross purposes if the expectations, however wrong, are disappointed. The LSG and vision documents can avoid such conflicts entirely (and the burden of managing them via complex governance) by not giving impressions that induce undue reliance. Writing (and coding) defensively on foundational issues enables one to create the space where we can work freely with common purpose.

17

The vision seems to address mainly Platform Steering Group (PSG) and platform owners. Would it be possible for the PSG to also coordinate a vision or guidance for contributors and developers in support of cross-platform development?

Most coders have primary concerns/goals and are willing to pick up cross-platform compatibility as a secondary goal, but it's hard to know what to do to achieve that: for contributors, which CI to run and what branches to pick/PR for; and for contributors and developers, how to configure the right #if compiler control branches, SPM conditional dependencies, CMake variables, etc. Insiders may have evolved their own practice, but it's a hurdle for others.

At a minimum I imagine the goal should be that tier 1-2 platforms should be representable in the relevant configuration languages - contingent dependencies and build logic, static compiler control and dynamic availability. I can also imagine situations where one would need conditional behavior based on the build host, i.e., the toolchain provider.

Similarly, Swift itself comes with a lot on Apple platforms that isn't available elsewhere, and packages like swift-system expressly adopt a multi-platform vision: instead of reducing all platforms to the subset of features always available (as Java might), it expressly often surfaces platform-specific features. Sometimes those features are addressable via canImport(Module), but not always. These platform variants need to be addressable, and ideally discoverable so that developers can plan accordingly.

Finally, there are often multiple ways to configure platforms and variants (in the command line, via SPM declarations, via environment variables, in build system defaults, ...), and some that require combinations (e.g., SIMD requiring Clang flags). The PSG can help drive documenting and clarifying (or simplifying or debugging) such configuration.

Regardless of whether variants are addressable or platforms are representable, people need guidance documents on what to do for a given Swift release. Even knowing that something's not possible yet is helpful.

I imagine the PSG and platform owners/candidates already understand and want to do this, and that there is overlap with the Language Steering Group. But I think potential contributor and developers would love to (eventually) see some principles, goals and plans around that in the PSG vision for evolution.