![Cover image for [Swift Philosophy #4] Swift Evolution and SE-0296](/assets/images/posts/d92caedf-939a-44c8-bad7-261591745177/1.jpg)
SE-0296 and SE-0345 often appear in Swift articles and release notes. SE-0296 accompanies async/await, while if let name shorthand syntax appears with SE-0345. What are these numbers?
They are registry numbers for every language change adopted by Swift. Even adding one syntax feature follows Swift Evolution, the public process through which proposals receive SE serial numbers. Contrary to Apple’s closed image, Swift’s evolution happens in a completely public ledger.
This is part 4 of the Swift philosophy series. The first three covered Swift’s values—safety, performance, expressiveness, progressive disclosure, and value types. This part covers the institution that protects those values: philosophy needs process to endure.
What Swift Evolution is — a public review process for language changes
In December 2015, Apple open-sourced Swift and published the process for deciding its future. The GitHub swift-evolution repository and Swift forums (forums.swift.org) are its stage.
The core rule is simple: anyone changing Swift syntax or the standard library must write a proposal and pass public review. Apple engineers—and even Chris Lattner—cannot bypass it. Early Apple proposals have been rejected by the community, while countless external proposals have entered the language.
What does this process protect? The philosophy from the previous three parts. The community, not just the proposer, checks whether a feature harms safety, breaks progressive disclosure, or remains consistent with existing code. Language consistency becomes an output of process, not one person’s taste.
A proposal’s life — from idea to syntax
Let’s follow, step by step, how a piece of syntax enters the language.
Step 1: Pitch. Post the idea in the forum’s Evolution > Pitches section. Constraints are loose; the goal is to gauge interest. The community suggests alternatives and exposes flaws. Most ideas are filtered out or substantially reshaped here.
Step 2: Write the Proposal. If the pitch survives, write a formal proposal. Its template reveals the process: Motivation, Detailed design, Source compatibility, ABI stability impact, and Alternatives considered. It asks not only why this design, but why not another.
Step 3: Attach an implementation. Current Evolution practice importantly requires working code with the proposal. Review starts only after the idea has been tested in the compiler. Feasibility is demonstrated in code, not argued on paper.
Step 4: Public Review. A review manager is assigned, and the forum usually hosts review for 1–2 weeks. The announcement lists questions: Does this solve an important problem? Does it fit Swift’s feel and direction? How does it compare with similar features in other languages?
Step 5: Decision. The Language Steering Group decides after review. The result is Accepted, Returned for revision, or Rejected, always with reasons. If accepted, the SE number is finalized and the implementation ships in a specific Swift version.
The weight of the process in real cases
Let’s examine several famous cases to see how the process works in practice.
SE-0296 async/await. This proposal launched Swift concurrency. Its direction appeared in Chris Lattner’s 2017 Concurrency Manifesto, but it took years of proposal, review, and approval to reach Swift 5.5. It was assessed alongside actor (SE-0306) and structured concurrency (SE-0304), forming one roadmap. Major features arrive as proposal groups, not isolated proposals.
SE-0345 if let shorthand. It lets you write if let name = name instead of if let name. Although small, the pitch sparked lengthy debate over alternatives such as if let name?. The final decision chose today’s syntax for its balance of brevity and clarity. Even minor syntax accumulates this level of reasoning.
Rejected proposals are recorded too. An early proposal to require self prefixes on function arguments (SE-0009) was rejected after review, and its reasons remain in the repository. The community found the added code noise outweighed the gain in explicitness. Recording rejection reasons also prevents the same debate from recurring.
A pattern emerges: Evolution records not only what entered, but what did not and why. It builds case law for language design.
Who decides — the governance structure
Who makes the final decision?
Swift’s Core Team sits at the top, while the Language Steering Group makes substantive language decisions. Apple engineers and external community members serve together. Forum sentiment informs them, but decisions are not by majority vote. Officially, review collects arguments rather than votes: the strongest evidence should win, not the loudest voice.
Apple’s influence is real: most compiler developers work for Apple, and Apple-platform needs, such as resultBuilder for SwiftUI, have driven proposals. Yet Apple cannot change syntax outside the process, and every discussion remains publicly searchable. As ecosystems beyond Apple platforms grow—server-side Swift and embedded Swift, for example—governance is also splitting into working groups.
Practical benefits for developers
Knowing Evolution has clear practical benefits for Swift developers.
First, top-quality learning material is free. When syntax is unclear, the proposal beats a blog post. It explains the problem, design rationale, and alternatives, revealing not just how to use a feature but why it looks that way. Find proposals by SE number on the swift.org/swift-evolution dashboard.
Second, you can preview the language’s future. The forum’s pitch board is a preview of Swift one or two years ahead. Today’s hot threads have repeatedly become syntax announced at the next WWDC.
Third, participation is genuinely open. Sharing usage experience in a review thread can be quoted in the decision. Practical feedback from Korean users on string handling or formatting proposals is more valuable than you might expect.
Fourth, it informs team technical decisions. Distinguishing an experimental feature flag, an approved feature, and an upcoming feature gives you grounds for deciding when to introduce it into production code.
Summary
- SE-XXXX is the number of a language-change proposal that passed Swift Evolution. Every Swift syntax change goes through this public process.
- The path is pitch → proposal, including alternatives → implementation → public review → Language Steering Group decision.
- Apple cannot bypass the process, and reasons for acceptance and rejection become public case law for language design.
- For new syntax, the proposal is the best source; the pitch board previews Swift’s future.
This concludes part 4 of the Swift philosophy series. We covered values—safety, performance, expressiveness—progressive disclosure, value types, and Evolution. Next comes a deep dive into fundamentals, starting with Swift’s most familiar question mark: what optionals really are.