swiftlang
swift-evolution
Markdown2015–2026
swiftlang / swift-evolution
swift-evolution
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
105Distinct people
154Mentions
2Explicit recommenders
15.9KGitHub stars
What to know before exploring
What it is
This maintains proposals for changes and user-visible enhancements to the Swift Programming Language.
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
I love Swift. Writing in it is awesome, the community is great, and it has traditionally been focused on a truly wonderful dev-focused experience. That being said, releases…
joshuawright11 used a recommendation phrase. 2 indexed comments match. This is a phrase match, not a verdict.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
No other repository is repeatedly linked in the same discussions.
This week on Hacker News
Nov 8–Nov 15 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/15/2026, 12:01:02 AM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year154 dated mentions
Observed mentions: 2015-12-03 17:04:39 UTC to 2026-07-10 11:39:51 UTC.
* An incomplete calendar period is marked with an outlined bar. Its count is not directly comparable with a full period.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2015 | 2015-01-01 00:00:00 UTC | 2016-01-01 00:00:00 UTC | 11 | 7 | 4 |
| 2016 | 2016-01-01 00:00:00 UTC | 2017-01-01 00:00:00 UTC | 24 | 4 | 20 |
| 2017 | 2017-01-01 00:00:00 UTC | 2018-01-01 00:00:00 UTC | 12 | 5 | 7 |
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 5 | 0 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 11 | 2 | 9 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 11 | 4 | 7 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 10 | 1 | 9 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 20 | 6 | 14 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 18 | 5 | 13 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 17 | 5 | 12 |
| 2026 (partial) | 2026-01-01 00:00:00 UTC | 2027-01-01 00:00:00 UTC | 5 | 0 | 5 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
Swift Evolution
https://www.swift.org/swift-evolution/
This repository tracks the ongoing evolution of the Swift programming language, standard library, and package manager.
Goals and Release Notes
Swift Language focus areas heading into 2025
CHANGELOG
Version
Announced
Released
Swift 6.4
2026-03-18
2026-09-15
Swift 6.3
2025-10-24
2026-03-24
Swift 6.2
2025-03-08
2025-09-15
Swift 6.1
2024-10-17
2025-03-31
Swift 6.0
2024-02-22
2024-09-17
Swift 5.10
2023-08-23
2024-03-05
Swift 5.9
2023-03-06
2023-09-18
Swift 5.8
2022-11-19
2023-03-30
Swift 5.7
2022-03-29
2022-09-12
Swift 5.6
2021-11-10
2022-03-14
Swift 5.5
2021-03-12
2021-09-20
Swift 5.4
2020-11-11
2021-04-26
Swift 5.3
2020-03-25
2020-09-16
Swift 5.2
2019-09-24
2020-03-24
Swift 5.1
2019-02-18
2019-09-20
Swift 5.0
2018-09-25
2019-03-25
Swift 4.2
2018-02-28
2018-09-17
Swift 4.1
2017-10-17
2018-03-29
Swift 4.0
2017-02-16
2017-09-19
Swift 3.1
2016-12-09
2017-03-27
Swift 3.0
2016-05-06
2016-09-13
Swift 2.2
2016-01-05
2016-03-21
Read the full README on GitHubWhat Hacker News says
18 sourcesSwift: Precise Control Flags over Compiler Warnings
1 points · Open discussionAdditional reading about how Swift Structured Concurrency (Task API) utilizes and propagates QoS is in the proposal doc.
https://github.com/swiftlang/swift-evolution/blob/main/propo...
In Prioritize work at the task level> given that FFI is usually in a thin layer of application code that can sort out safety itself.
Apple is aiming far higher. They want [1] the ability to seamlessly replace C++ code anywhere with Swift code, to write subclasses of C++ classes in Swift, etc. without giving up performance.
See https://github.com/swiftlang/swift-evolution/blob/main/visio...
and the video linked to in https://forums.swift.org/t/video-swift-as-c-successor-in-fou..., which shows how far they were a year ago.
[1] they likely won’t get there for all C++ code, but if they get to “with a few manual annotations” without giving up efficiency, that would be a major accomplishment.
In Safe and efficient C++ interoperability via non-escapable types and lifetimesI think your link got cut off. Here’s the direct link to the section on when to use typed throws. I hadn’t read this before, and it changes how I’ll approach them. Thanks for pointing it out!
https://github.com/swiftlang/swift-evolution/blob/main/propo...
In Swift 6You can read about the trade-offs in the language proposal here: https://github.com/swiftlang/swift-evolution/blob/main/propo...
In particular:
> Even with the introduction of typed throws into Swift, the existing (untyped) throws remains the better default error-handling mechanism for most Swift code. The section "When to use typed throws" describes the circumstances in which typed throws should be used.
In Swift 6Swift's ownership features are still new and going through evolutions; so its current state isn't the necessarily the vision or where it will be in a year. E.g., here's a proposal that allows one to create a lifetime dependency between a function's return value and its parameters: https://github.com/apple/swift-evolution/blob/d9aa90bae13e35...
In Deep Dive into Ownership in MojoObjective-C Implementations in Swift
2 points · Open discussionObjective-C Implementations in Swift
3 points · Open discussionAccording to their changelog[0], Clock was added to the standard library with Swift 5.7, which shipped in 2022, at the same time as iOS 16. It looks like static linking by default was approved[1] but development stalled[2].
I expect that it's as simple as that: It's supported on iOS 16+ because it's dynamically linked by default, against a system-wide version of the standard library. You can probably try to statically link newer versions on old OS versions, or maybe ship a newer version of the standard library and dynamically link against that, but I have no idea how well those paths are supported.
0. https://github.com/apple/swift/blob/main/CHANGELOG.md
1. https://github.com/apple/swift-evolution/blob/main/proposals...
2. https://github.com/apple/swift-package-manager/pull/3905
In Swift's native Clocks are inefficientThank you for the compliment!
We're working on improving its support for other use cases, with work to better support embedded[1], server[2], and AI[3] use cases, along with Linux[4] and Windows[5] support.
We're also putting a lot of energy into improving support for these scenarios in Visual Studio Code [6].
Would love to hear more about scenarios folk are looking at, as well as specific gaps that are blocking you adopting Swift for non-Apple platforms. We're building a roadmap now and would love to make sure our work items are comprehensive.
[1] https://github.com/apple/swift-evolution/blob/main/visions/e...
[2] https://www.swift.org/blog/sswg-update-2024/
[3] https://www.swift.org/blog/mlx-swift/
[4] https://www.swift.org/blog/adwaita-swift/
[5] https://www.swift.org/blog/swift-everywhere-windows-interop/
[6] https://marketplace.visua
Read the rest
That is the direction that Swift went: https://github.com/apple/swift-evolution/blob/main/proposals...
In Overview: What are Cpp2 and cppfront? How do I get and build cppfront?A Vision for Embedded Swift (https://github.com/apple/swift-evolution/blob/main/visions/e...) has the details on this new build mode and is quite interesting.
Effectively, there will be two bottom layers of Swift, and the lower one, “non-allocating” Embedded Swift, will necessarily be a more restricted compilation mode (e.g. classes will be disallowed as they fundamentally require heap allocations) and likely to be used only in very specialized use cases. “Allocating” Embedded Swift should allow classes and other language facilities that rely on the heap (e.g. indirect enums).
Also, this seems to maybe hint at (most of?) the Swift runtime eventually being reimplemented in non-allocating Embedded Swift rather than the C++ (?) that it uses now:
The Swift runtime APIs will be provided as an implementation that’s optimized for small code
Read the rest
size and will be available as a static library in the toolchain for common CPU architectures. Interestingly, it’s possible to write that implementation in “non-allocating” Baremetal Swift.
Detailed rationale is in the Swift Evolution proposal (https://github.com/apple/swift-evolution/blob/main/proposals...)
This also isn’t a problem specific to Swift. Many strongly typed languages run into it.
Examples:
- C# (https://learn.microsoft.com/en-us/dotnet/api/system.tuple-8?...):
public class Tuple<T1,T2,T3,T4,T5,T6,T7,TRest>
- Scala (https://www.scala-lang.org/api/2.13.6/scala/Function22.html):
trait Function22[-T1, -T2, -T3, -T4, -T5, -T6,
-T7, -T8, -T9, -T10, -T11, -T12,
-T13, -T14, -T15, -T16, -T17, -T18,
-T19, -T20, -T21, -T22, +R] extends AnyRef
- Java (https://www.javatuples.org/index.html; third party)
In Iterate over Parameter Packs in Swift 6.0Showing the 15 most recent of 18 sources. Enable JavaScript to search and browse every indexed mention.