Swift Evolution makes proposal status searchable

An accepted language proposal can describe a feature that no released compiler supports. That distinction becomes difficult to track when design discussion, review decisions and implementation work live in different places. Swift's new Evolution status page puts those records within reach of a searchable proposal list. The useful improvement is the connection between a language decision and the work needed to make it usable.

Kyle Murray's January 18 announcement says the community has contributed more than one hundred proposals. The page supports keyword searches across topics, authors and review managers. It can also narrow the list to proposals implemented in a particular Swift version and display the current states of associated implementation issues. These are different views of the same process, each answering a different question about a proposed change.

I find Swift consistently well designed, but judging a design and deciding whether a toolchain can use it are separate tasks. A status page helps with that distinction. Reading a proposal should not require guessing whether its examples describe the installed language or an accepted future extension.

Acceptance and implementation are different states

The Swift Evolution process document as it stands before this announcement defines the states that give the dashboard meaning. An accepted proposal can be awaiting implementation or already under implementation. An implemented proposal includes a Swift version number. When implementation spans versions, the process says to record the version in which it will be complete.

That convention makes the version filter useful for a concrete compiler decision. Filtering for implemented proposals is stronger evidence of availability than filtering for accepted proposals. Even then, the proposal text remains necessary to understand the feature's scope. A label cannot explain the language rules or the limitations that the review accepted.

Other states record why a proposal has not become an implemented feature. A proposal can return for revision, or its author can withdraw it. Deferral means it does not fit the upcoming major release's goals and should be reconsidered when the next release is scoped. Rejection records a considered decision against the proposal. Treating all of these as unfinished work would discard information about the decision already made.

The process also distinguishes acceptance with revisions. That state ties approval to specified changes in the design. It is therefore useful to read the reviewed document and the decision together, especially when an older discussion quotes a draft that no longer represents what the core team approved.

The repository supplies the data

The announcement explains that the page updates automatically from changes to proposal Markdown in the Swift Evolution repository. A merged pull request changing a proposal's metadata will appear on the status page afterward. Contributors do not need to maintain a separate manually edited announcement page to keep this view current.

This arrangement gives proposal maintenance a visible consequence. The process assigns the review manager responsibility for updating a proposal's state after the core team decides. The dashboard then presents that state to readers browsing the language's development. An inaccurate label in the document can become an inaccurate label in the searchable view, so the document remains the record that needs correcting.

The implementation-issue connection answers another question that a decision alone cannot settle. An accepted design may require several pieces of engineering before it is complete. Displaying the associated issue states lets readers follow the implementation work without interpreting acceptance as a release announcement. The page combines those signals while preserving their separate meanings.

Search supports participation in review

Swift Evolution covers language changes and changes to the standard library's public interface. The process includes small API changes as well as larger language additions and removals. Ordinary bug fixes, optimizations and diagnostic improvements can instead use the normal contribution process. The proposal list consequently describes a particular class of decisions, rather than every change made to the compiler.

Before proposing a change, the process asks contributors to check earlier proposals and discussions. Search by topic reduces the effort involved in that prerequisite. An author search can help locate related work by a particular contributor, while the review-manager field helps identify who coordinated a decision. These searches provide ways to find context that a remembered proposal title might not supply.

A prospective proposal still needs a problem statement and a developed solution. The process encourages prototypes to examine feasibility and show that the design solves its intended problem. Public review begins after a sufficiently developed proposal enters the repository, with a proposal number and a core-team review manager. Reviews usually last a week, although complex proposals can require longer.

I value the ability to inspect that history because Swift's appeal depends partly on how its features fit together. A short example can make an isolated change look attractive. Earlier proposals and review decisions help explain whether the same idea has already conflicted with another part of the language or exceeded the scope of the next release.

The dashboard does not change who decides a proposal. The core team retains responsibility for the language's direction and the authority to accept or reject changes. Reviewers contribute evaluations that address the problem's significance, the fit with Swift and comparisons with related designs. Search makes those decisions and their implementation status easier to find, while the process document still defines how a proposal reaches review and how its outcome is recorded.