Swift.org, the Open Source Project

On December 3, 2015, Apple made version 2.2 of the Swift programming language open source software by creating Swift.org and contributing a key set of source code repositories covering the compilers, debuggers, libraries, and more. The Swift.org site (https://swift.org) was set up to serve as a central hub for this new community. The site contains documentation, binary downloads, links to the open source repositories on GitHub, mailing lists, and bug reporting mechanisms, as well as continuous integration support to maintain stability across the projects. In this chapter, I will cover what is included on the site as well as some pointers about how to get involved in this exciting community.

What’s Included

The Swift.org website is the focal point for the Swift language development community. Because the community supporting Swift is composed of people with diverse skill levels and different interests, the site is designed to be a single entry point from which visitors can access the information relevant to their needs. The navigation categories listed on the left-hand side of the Swift.org home page represent major topic areas into which visitors can dive, depending on whether they are developers who want to look at the source code, testers wanting to report a bug, people with general interest who want to subscribe to a mailing list, or any of the dozens of possible reasons why they are involved with the language.

There are roughly a dozen of these major navigation categories on the Swift.org home page. Visitors can learn general information about the language by following the About Swift link. They can access public blogs and documentation by clicking on those same named links. They can learn about the rules of the community and how to contribute through the Community and Contributing links. You will learn more information about community involvement later in this chapter.

For developers, one of the most important Swift.org categories is the Source Code link. All of the source code for the Swift language and related utilities is stored in GitHub repositories (a separate website from Swift.org). The SOURCE CODE navigation link from the Swift.org home page takes you to a web page where the organization of the source code is explained and links are provided to the various GitHub repos containing code for different Swift libraries.

Source Code Repositories

The open source Swift language is managed by the community as a collection of projects, each with its own source code repositories. These repositories are the core of Swift.org. Anyone can freely access the source repositories to get the code for the Swift language, build it, and run their own local version; they can even make enhancements or fix defects as long as the community rules for contributions are followed. These source code repositories include the following:

• Swift compiler and standard library
  • https://github.com/apple/swift
• Core libraries (Foundation, libdispatch, and XCTest)
  • https://github.com/apple/swift-corelibs-foundation
  • https://github.com/apple/swift-corelibs-libdispatch
  • https://github.com/apple/swift-corelibs-xctest
• LLDB debugger and REPL
  • https://github.com/apple/swift-lldb
• Swift Package Manager
  • https://github.com/apple/swift-package-manager
• Xcode Playground Support
  • https://github.com/apple/swift-xcode-playground-support
• A variety of repositories that include support for compiler tools, tests, code samples, protobuf support, and much more

These projects are published under an Apache 2 license with a runtime library extension. The importance of this kind of license is that it solves the potential problem of a schism between the compiler and runtime library by allowing both to be covered uniformly under the same license.

Figure 1-1 shows the GitHub web page for a typical Swift.org repository—in this case, for the Swift compiler and standard library project.

Figure 1-1: One of the Swift.org source repositories

Swift Compiler and Standard Library

The Swift compiler and standard library provide basic language and type system support across the platforms. This support is completely equivalent for macOS and Linux, but no other operating systems are supported as of this writing. All the language features described in this chapter are delivered by the compiler and standard library.

The Swift standard library supplies a programmer with the fundamental data types such as Int, Double, and String, as well as more complex data structures including Set, Array, Dictionary, and many more. It is within this library that many common protocols are defined for the language features. Many language features have a corresponding protocol, and any type that conforms to the protocol can be used with that feature. For example, a for-in loop can iterate over the elements of any value whose type conforms to the Sequence protocol.

Foundation

The Foundation library provides many core capabilities that Swift developers are accustomed to, such as URLSession, JSONSerialization, and more. On Apple platforms, this library is implemented in Objective-C. The Swift.org version of this library is being implemented in Swift. As such, there are several APIs in Foundation that are being rewritten to make Foundation support on Linux more mature. To view the latest status of Foundation, you can check the status page at https://github .com/apple/swift-corelibs-foundation/blob/master/Docs/Status.md.

Libdispatch (Grand Central Dispatch)

Swift developers are accustomed to using Grand Central Dispatch to leverage concurrency support in their applications running on client operating systems such as iOS. Grand Central Dispatch support is provided within the libdispatch core library. This library is provided as part of the Swift runtime. When Swift was first made open source, the libdispatch core library was included as part of Swift.org. At that time, the library had not been ported to Linux. IBM agreed that it was important to provide this same consistent concurrency support on Linux, and set about porting libdispatch to Linux. The ported version of libdispatch was included in the Swift 3.0 release in September 2016. This was an important milestone because many Foundation APIs (like OperationQueue and URLSession) also depend upon libdispatch.

Debugger and REPL

Tight integration of the Swift compiler and debugger enables accurate inspection of data types in the debugger, as well as full-featured expression evaluation in the context of this rapidly evolving language. However, because of this tight integration, developers must be sure to use a matched pair of a compiler and debugger built using the same sources. Debugging using a mismatched compiler-debugger set will lead to unpredictable behavior and programming problems.

The swift-lldb repository contains the source code that can be used to build the Swift debugger. The debugger includes an interactive version of the Swift language, known as the REPL (read-eval-print loop). You can use this interactive command environment to experiment with Swift and quickly see the results of arbitrary Swift code snippets that you write and execute. You can try the Swift REPL environment on your macOS computer by simply typing swift on the Terminal command line:

All you need to do is type Swift statements, and the REPL immediately executes your code. Expression results are automatically formatted and displayed along with their type, as are the results of both variable and constant declarations.

The swift-lldb project wraps enhancements around the core LLDB (Low Level Debugger) open-source debugger project developed under the broader LLVM (Low Level Virtual Machine) project, located at llvm.org. Therefore, any code modifications that are contributed to swift-lldb will undergo extra scrutiny because of the potential impact outside of the Swift language ecosystem.

Swift Package Manager

Swift Package Manager is a new feature that was introduced with Swift 3.0. Although it is not yet used for building applications on other Swift platforms, it is used extensively for building applications on Linux. Projects that are compatible with Swift Package Manager are built around a Package.swift file that specifies build targets as well as other packages that the project is dependent upon. Chapter 6 is devoted to Swift Package Manager and all of its details.

Xcode Playground Support

The “playground” feature in Xcode has long been used by developers to experiment with a language, explore its standard library types, and learn high-level concepts using visualizations and practical examples. Within Xcode there are several “playgrounds” supported for different languages. For instance, a programmer can use the Xcode Swift Playground to learn how the Swift language uses protocols and generics to express powerful constraints. The playground feature is valuable for developers who are new to the language, but also very handy for those who are well versed in the behavior of the language.

The Xcode Playground Support project enables the Swift language to be integrated with the Xcode playground feature so that developers can take advantage of the playground to learn and explore the language. This same project code is used outside of Xcode for similar language learning “playground” systems such as the Bluemix Swift Sandbox (see Chapter 2 ).

Other Related Projects and Repositories

The Swift.org open source code builds upon other, earlier open source projects. This has the advantage of leveraging years of previous innovation and thousands of hours of hard work contributed by developers all over the world. However, this approach to building Swift comes with the price of requiring very careful cloning and merging with the source code of the open source projects on which the Swift implementation depends.

Swift.org development follows a policy of pushing any changes to the most upstream repository feasible. This means that contributions to Swift code that involve the repositories of open source projects on which Swift depends will be pushed to the code base for those other projects rather than residing in a version of the code only applicable to Swift. This, in turn, means that any such code changes will be reviewed by multiple open source project teams before being accepted, not just Swift.org.

The open source projects on which Swift.org code has dependencies include LLVM Core, Clang, and LLDB. Swift.org maintains cloned copies of those other projects’ repositories and frequently updates these clones as the code evolves in the other projects.

How to Get Involved

There are many ways to work with and contribute to the open source Swift community. You do not have to be an expert developer of programming languages or compilers in order to make valuable contributions. You can start getting involved by subscribing to the mailing lists for the community and providing answers that you have to the questions that are posted there. The community encourages everyone to submit bugs that they uncover while using Swift. When reporting bugs for Swift, be sure to follow the guidelines described at https://swift.org/contributing/#reporting-bugs for information that you need to provide as part of the bug report. When filing a bug report, it is important to distinguish the difference between a new language feature and a defect in the existing, defined language features. New feature requests must go through the Swift evolution process, whereas bug reports are submitted to the Swift bug tracking system.

Another way to get involved in the Swift community is to take part in triaging reported bugs. Once a bug report has been submitted, someone must validate the bug by reproducing it. Additional information may be needed to augment the bug report so that Swift developers can more efficiently address it. The bug report may also be a duplicate of another already-existing bug report. Triaging bug reports for the community is an extremely valuable contribution to improving Swift.

Many members of the community are enthusiastic about contributing code changes for Swift. Full guidelines for making these code contributions are found at https://swift.org/contributing/#contributing-code. There are several considerations for contributing code to the project, including the following:

• Use short-lived code branches containing small, incremental changes—Small changes are easier to track and integrate. Longer-lived branches tend to result in messy code-merge problems and are discouraged.
• Keep each change self-contained—Every commit should be able to be shipped in a release without dragging along other uncommitted changes.
• Use clear and thorough commit messages for all code changes—Your code change will be reviewed and examined by many other developers, so it is crucial that you sufficiently describe what you changed so that others can quickly understand.
• Use the developer email list to keep the community aware of what you are doing.
• Use the designated source code header when committing new source files—This ensures that the license and copyright protections are called out at the top of every Swift.org source file.
• Expect and actively participate in the code review for your change. Code review is often an iterative process; it is carried out in the open through GitHub and reflected in the associated commit email list postings.
• Provide test cases for all bug fixes and code changes—Tests are considered a required component of any code modification, and your change will not be committed without them.
• Be prepared to rapidly address any failures that your code change may cause in the Swift continuous integration (CI) once the code has been committed.
• Stay alert for potential regressions that your code change may cause, even days after it has been initially committed—When you submit a code change to the community, your responsibility to support it is ongoing and long lasting.
• Avoid adding new external code libraries as part of making a code change—External libraries may not follow the same license and legal rules as the rest of the Swift.org code, and there may be issues with compatibility of the external code across all supported Swift target platforms.

As with any vibrant open source community, it is important to support communication across a wide range of interests within the community. This communication within Swift.org is handled via mailing lists, shared source repositories (such as GitHub.com and Swift.org), and bug tracking. I’ve already covered the shared code repositories, so let’s consider mailing lists and bug tracking.

Mailing Lists

Swift.org has defined and set up several mailing lists targeting certain personas and their interests in different parts of the project. Mailing lists are considered to be the primary method of communicating among community members, and the volume of interaction is high on the main topic lists. The General Interest list is the most popular, covering most common questions related to the use of the Swift language rather than issues related to its development.

The set of Swift Developer mailing lists is used by programmers who are actively delivering contributions to the open source code-base for Swift, and the mailing lists are organized based on the Swift.org project and code repository that the users are discussing. The Swift Evolution lists focus on encouraging and reviewing proposals for new language features. Swift.org has a well-defined and open process for the evolution of the language, and these lists, along with the Swift Evolution Repository (https://github.com/apple/swift-evolution), support that process.

Figure 1-2 shows the web page where you can register to participate in one of the Swift email lists. For more information on these mailing lists and to sign up for any of them, go to https://swift .org/community/#mailing-lists.

Figure 1-2: Email list signup page for the Swift General Interest group

Discussion lists

Some of the email lists for Swift.org are interactive and encourage a free flow of discussion exchange. Other lists are for one-way communication to notify subscribers about something with no expectation that they respond. The discussion email lists are further divided into categories based on the subscriber’s role. These discussion categories and their associated email lists are organized as follows:

• General Interest
  • swift-users —For questions regarding Swift and its related tools

• Swift Developers
  • swift-dev —Swift compiler, low-level runtime, standard library, and SourceKit
  • swift-corelibs-dev —Swift core libraries
  • swift-server-dev —New server-focused capabilities developed by the Server APIs workgroup
  • swift-lldb-dev —Swift REPL and Swift-specific aspects of LLDB
  • swift-build-dev —Swift Package Manager and low-level build system (llbuild)

• Swift Evolution
  • swift-evolution-announce —Swift evolution proposal reviews and results (low volume)
  • swift-evolution —A discussion of the evolution of Swift, its libraries, and more. This is a very active mailing list, so subscribing via digest might be the best option.

You can find more information on the Swift evolution process and current focus at https://github.com/apple/swift-evolution.

Notifications

There are also many notification lists that contain commit messages for the various Swift.org project repositories. These lists are fed from automatically generated content and should not be used for discussion of any kind. Actual interactive discussion occurs on the other previously described mailing lists and in the content of GitHub Issues in the source code repositories for each project.

When a developer commits source code changes to one of the project repositories, an email message is generated and sent to the corresponding notification list. Other developers and interested stakeholders can monitor the notification email lists and keep up with changes occurring to the source code for Swift.

The Swift.org notification mailing lists include swift-commits, swift-lldb-commits, swift-corelibs-commits, and swift-build-commits.

Bug Tracking

Like any software, the code for Swift.org contains defects—bugs! And, like any well-run software development project, Swift.org has a system for reporting and tracking bugs in the code. Swift.org manages bugs and code issues with a JIRA-based bug-tracking site. This site can be used to open issues to report defects and problems against any part of the Swift.org ecosystem. It can also be used to find the latest information about updates that might be included in future releases. The Swift.org bug-tracking system is maintained at https://bugs.swift.org.

In order to log in to the Swift bug-tracking tool, you have to create an account. It is free to create a JIRA account for the Swift.org bug-tracking tool, and it only takes a couple of minutes. Figure 1-3 shows the web page that you use to sign up for a new Swift.org JIRA account, and the information required.

Figure 1-3: Sign-up web page for a Swift JIRA bug-tracking account

After you create a Swift.org bug-tracking system account, you can return to the login web page, which also serves as the system dashboard. On this page, you can see a feed of recent project activity and log in to your new account. Figure 1-4 shows a typical dashboard view.

Figure 1-4:Swift.org bug-tracking dashboard and login page

When you log in to the Swift.org bug-tracking system, the first page you see gives you a choice of three activities to pursue, as shown in Figure 1-5. You can choose to begin the process of creating and submitting a new bug report about some defect in the Swift code. Or, you can search for bug reports that match some criteria that you’re interested in. Perhaps someone else has already submitted a bug report for the same problem that you are experiencing and it would save you time if you didn’t have to create a duplicate. The third path allows you to explore the projects and view Kanban boards of the associated work, as well as generate reports about various metrics that are measured against the activity tracked in the system.

Figure 1-5:Swift.org bug tracking—what would you like to do now?

Figure 1-6 shows the web page where you can browse the list of projects to explore. The list shown in the figure only contains the main Swift.org project. By clicking the Boards tab in the main menu bar, you can access a web page that shows a list of the available Kanban boards, as shown in Figure 1-7.

Figure 1-6:Swift.org bug-tracking Projects list

Figure 1-7:Swift.org bug tracking, showing a list of Kanban boards

From the Kanban board list, you can select a board to view, or you can choose to see all of the issue cards consolidated on one board for all projects, as shown in Figure 1-8.

Figure 1-8:Swift.org bug tracking, showing the Kanban board for all projects

Whether you plan to become heavily involved in contributing to the Swift.org projects or you just want to explore the activity that is underway in a project, the bug-tracking tool for Swift.org is a valuable application to know how to use.

Swift Evolution and Roadmap

The Swift.org community established the Swift evolution process to define a consistent way for a proposed language feature to grow from a rough idea into something that can “improve the Swift development experience” and be included in an upcoming release. ¹ The evolution process covers all changes to the Swift language, including any new language features or API (application programming interface) enhancements. This process strives to balance and achieve two conflicting goals:

• Provide an open, transparent, robust, broad community involvement in improving the language
• “Maintain the vision and conceptual coherence of Swift” ²

Everyone is welcome to propose new ideas for improvement of the Swift language, and to engage in the review and discussion of these ideas. However, there is a core team that is ultimately responsible for the strategic direction of the Swift language and that has the authority to accept or reject proposed changes. The members of this core team will change over time, but the latest membership list can be found on the Swift.org Community web page at https://swift.org/community/#community-structure.

Every proposal for a new feature undergoes a thorough, public review and discussion before being accepted or rejected. Each proposal is considered in relation to the specific goals for the upcoming release, whether the proposal is significant enough to warrant making the change to Swift, and whether the proposal fits well with the direction of the language, especially compared with other programming languages and ecosystems.

To participate in this evolutionary process for Swift, you can follow the instructions documented at https://github.com/apple/swift-evolution/blob/master/process.md and submit a proposal for consideration. Once submitted, your proposal will progress through various states in the process until its ultimate status is determined. As of this writing, the states that your proposal may inhabit will be one of the following:

• Awaiting review —The proposal is awaiting review. Once known, the dates for the actual review are placed in the proposal document and updated in the list of proposals. When the review period begins, the review manager updates the state to Active review.
• Scheduled for review (MONTH DAY. . .MONTH DAY) —The public review of the proposal on the swift-evolution mailing list has been scheduled for the specified date range.
• Active review (MONTH DAY. . .MONTH DAY) —The proposal is undergoing public review on the swift-evolution mailing list. The review continues through the specified date range.
• Returned for revision —The proposal has been returned from review for additional revision to the current draft.
• Withdrawn —The proposal has been withdrawn by the original submitter.
• Deferred —Consideration of the proposal has been deferred because it does not meet the goals of the upcoming major Swift release. Deferred proposals are reconsidered when scoping the next major Swift release.
• Accepted —The proposal has been accepted and is either awaiting implementation or is actively being implemented.
• Accepted with revisions —The proposal has been accepted, contingent upon the inclusion of one or more revisions.
• Rejected —The proposal has been considered and rejected.
• Implemented (Swift VERSION) —The proposal has been implemented. The version number is appended in parentheses, for example, Implemented (Swift 2.2). If the proposal’s implementation spans multiple version numbers, the version number is indicated for the implementation that will be complete.

Priorities for the Swift 4.0 Major Release

When Swift was first made open source on December 3, 2015, the official release number at that time was 2.2. From that point on, the Swift language evolution process was followed in order to plan for a 3.0 release in September 2016. Version 3.0 of Swift included many breaking changes in the source and in the API. However, this was done intentionally to avoid any additional breakages in subsequent releases. As of this writing, you can look forward to version 4.0 in 2017, with the Swift community focusing primarily in that release on source stability and ABI (application binary interface) compatibility.

ABI compatibility is important because it allows a developer to create a pre-built library of Swift code using one version of the compiler, and then another developer can link their application with that pre-built Swift library without having to worry about using the same version of the compiler that was used to build the library. There is no ABI compatibility for Swift release 3.0 and earlier, and so developers of application frameworks and libraries have to create multiple compiler-specific versions of their deliverable. Also, the developers who want to consume these libraries need to ensure that the compiler they use for their application matches the one used to build the linked binary libraries. With only a few versions of the Swift compiler released, this has not yet become a serious problem. However, as more versions are released, the critical need for ABI compatibility will increase.

Of course, the concern about lack of ABI compatibility can be (and is being) addressed by developers distributing their libraries in source code instead of binary format. Source-code distributed libraries will be compiled by the same compiler that is used for the main application. So, in theory, this mechanism for distributing libraries will always be “compatible.” However, there are some problems with source code distributed libraries. For example, many developers want to distribute libraries in binary form so that they can protect their intellectual property contained in the library code. Commercial products offered for sale, that include libraries or frameworks, are especially concerned about preventing code piracy, and ABI compatibility is a crucial feature for them. Furthermore, even source level compatibility has not been fully realized between Swift language releases (at least up to 3.0).

You can find more information on these focus areas at https://github.com/apple/swift-evolution/.

Binary Downloads

Swift.org binary releases (https://swift.org/download/) include installable versions of Swift for Apple macOS as well as Ubuntu Linux hosts. These releases are organized as official releases, preview releases, and development snapshots.

The official releases are typically what you should use for developing applications using Swift. Preview releases are useful to test whether your existing application contains any language usage that is broken by planned upcoming language enhancements. Development snapshots are most often used by programmers who are actively working on the actual language. Having all of these binary versions of the language available for download demonstrates the openness and transparency for public scrutiny that characterizes Swift.org operating practices.

MacOS Binaries

On macOS, the most recent Xcode version includes the latest official Swift language binaries. So, if you already have Xcode installed and updated on your system, you should not need to download a binary release from Swift.org unless you are planning to work on upcoming releases of the language or to test your app against a preview release. It is very important to keep in mind that in order to submit an app to the Apple App Store, you must build your app using the version of Swift that is included within Xcode. The supported target platforms for production apps using Swift are:

• macOS 10.9.0 or later
• iOS 7.0 or later
• watchOS 2.0 or later
• tvOS 9.0 or later

There are installation instructions on the Swift.org website for how to set up a downloaded version of Swift binaries to be used by Xcode instead of the default version that ships with Xcode. Note that setting up the Xcode IDE tool to use a different version of Swift does not change what is used by the command line (xcodebuild and xcrun commands). You must either modify the PATH environment variable to put the new Swift release /bin directory ahead of other paths, or else use the explicit -toolchain parameter on the command line invocation:

or

The .pkg package file downloaded from Swift.org and all the binary files contained in the package are digitally signed by the developer ID of the Swift open source project so that you know you have the official version and not code that has been tampered with.

The Swift Toolchain Installer program on macOS should display a lock icon on the right side of its title bar. Clicking the lock brings up detailed information about the signature (see Figure 1-9). The signature should be produced by “Developer ID Installer: Swift Open Source (V9AUD2URP3).” If the lock is not displayed or the signature is not produced by the Swift open source developer ID, do not proceed with the installation. Instead, quit the installer and send an email to swift-infrastructure@swift.org with as much detail as possible. The importance of ensuring that you are only using binary images produced by Swift.org cannot be overstated. Images that come from other sources may contain malware or other undesirable content that you would not want to include in your application and unknowingly put into production.

Figure 1-9: Swift Toolchain Installer showing signature detail

Linux Binaries

The Swift language packages are built and tested against the Ubuntu 14.04 and 15.10 (64-bit) Linux distributions. This does not mean that Swift only works on these distributions of Linux, only that these are the two distributions that Swift.org uses for testing and verification.

Before attempting to install a downloaded Linux binary package for Swift, you need to install some prerequisite libraries—clang and libicu-dev:

You can then install the downloaded TAR archive for Swift to any location as long as the extracted /bin directory is included in your PATH environment variable.

The first time that you install Swift on a Linux host, you have to import the supplied PGP keys into your keyring. Once this is done on a given Linux system, it does not have to be repeated for subsequent binary downloads and installation.

Swift packages that are downloaded to Linux are digitally signed with keys of the Swift open source project. For the same reasons that macOS binary release packages must be checked to ensure that they haven’t been tampered with, Linux binary packages must also be verified.

The Swift.org download web page includes a section about the Active Signing Keys used by the project and how to obtain them. You use the GPG command on Linux to verify the signature of the Swift.org binaries. GPG is an encryption and signing tool for Linux operating systems; it is used along with the active signing key from Swift.org to confirm that the binary download truly matches the package produced by the open source project. If you follow the verification instructions, and the gpg command fails to verify and returns a report of “BAD signature,” do not use the downloaded package. Instead, send an email to swift-infrastructure@swift.org to report the situation along with as much detail as possible.

Swiftenv, Swift Version Manager

Due to the dynamic and rapid evolution of the Swift language, developers using Swift need to juggle multiple release levels of the language on the same workstation. Manually switching between different releases of Swift on the same system can be slow, cumbersome, and error-prone.

In order to address this issue, the community has rallied around a tool called swiftenv to help developers manage multiple versions of the Swift binaries on both macOS and Linux. This tool and the instructions for installing it can be found at https://github.com/kylef/swiftenv. You can install the tool from this GitHub project or by using the Homebrew tool, which is probably the easiest method.

The swiftenv tool allows developers to set a global version of Swift to use as the default on their system. This default language release level can be overridden by changing an environment variable, as well as configured specifically for each project implemented using Swift.

The swiftenv tool offers integration with multiple continuous-integration build tools such as Travis CI, GitLabs CI, and CircleCI. This integration helps ensure that your automated build and deploy system always uses the proper release version of the Swift language, rather than whatever may be the default version that is accessed first in the environment PATH.

Several Docker images are also available that contain swiftenv. The Docker images are based on Ubuntu Linux and include a release version of the Swift language in addition to the Swift Version Manager tool. A buildpack is also available for Heroku so that you can automatically install the local version of Swift that you’ve specified in that environment. Documentation for Swift Version Manager is available at https://swiftenv.fuller.li/en/latest/.

Summary

The Swift.org open source community is an active group composed of representatives from many high-tech companies, as well as passionate individuals committed to the transparent development of the language and its supporting libraries and tools. You can follow the development and evolution of Swift by getting involved in this community and contributing in one of several different ways.

The Swift.org community depends on involvement from a broad range of users—from beginning programmers to seasoned developers. You have many choices for how to, and how much to, contribute, so you can tailor your involvement to fit your needs, skill level, and available time. Of course, by finding your own way to become involved in the Swift evolution process, you may discover that you have gone through your own evolution at the same time!

Notes

¹https://github.com/apple/swift-evolution/blob/master/process.md

²https://github.com/apple/swift-evolution/blob/master/process.md