> I have a better solution: address the root cause of unsafe semantics by not using raw indexed for-loops, unless one absolutely needs an index, in which case one should generate it with std::views::enumerate.
That’s why Swift completely removed that kind of for loop (https://github.com/swiftlang/swift-evolution/blob/main/propo...)
> This stuff compiles to broadly the same assembly.
At the cost of requiring a more complex compiler. Also, C/C++ won’t find “broadly the same” sufficient. They’ll want to see the same performance.
In Almost Always Unsignedswiftlang
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 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 1:49:46 PM 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
154 sourcesSwift has a RegexBuilder[1][2] interface, in addition to the usual string-ey interface that allows composition.
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
[2]: https://developer.apple.com/documentation/regexbuilder
In Regular expressions that work “everywhere”>[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.
These kinds of features are not intended for use in daily application development. They're systems-language features designed for building high performance, safe, very-low-level code. It will be entirely optional for the average Swift developer to learn how to use these features, just in the same way that it's optional for someone to learn Rust.
In Why Objective-CI really miss Objective-C, and in the world of Swift craziness [1] I'm reminded often of this blog post [2] wondering what would have happened if Apple hadn't encountered Second System Syndrome for its recommended language.
(There's a decent argument it encountered it in iOS and macOS too.)
[1] https://github.com/swiftlang/swift-evolution/blob/main/propo... -- apologies to the authors, but even as a previous C++ guy, my brain twisted at that. Inside Swift is a slim language waiting to get out... and that slim language is just a safer Objective C.
[2] https://medium.com/goodones/pareto-optimal-apple-devtools-b4...
In Why Objective-Chttps://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
https://github.com/swiftlang/swift-evolution/blob/main/propo...
All of these changes improve the ergonomics of async/await. Fewer hops and a better alignment of when one would expect a hop to occur.
https://github.com/swiftlang/swift-evolution/blob/main/propo...
async defer is nice too but it's not in the 6.2 public release AFAICT.
In Swift is a more convenient Rust (2023)The practical reality is arguably more important than beliefs. Apple has, as it turns out, invested in trying to make Swift more suitable for kernel and similar development, like trying to automate away reference counting when possible, and also offering Embedded Swift[0], an experimental subset of Swift with significant restrictions on what is allowed in the language. Maybe Embedded Swift will be great in the future, and it is true that Apple investing into that is significant, but it doesn't seem like it's there.
> Embedded Swift support is available in the Swift development snapshots.
And considering Apple made Embedded Swift, even Apple does not believe that regular Swift is suitable. Meaning that you're undeniably completely wrong.
[0]:
https://github.com/swiftlang/swift-evolution/blob/main/visio...
In Rust in the kernel is no longer experimentalSwift gained limited support for “typed throws” in Swift 6.0 (2024).
https://github.com/swiftlang/swift-evolution/blob/main/propo...
I say limited because the compiler doesn't (yet, as of 6.2) perform typed throw inference for closures (a closure that throws is inferred to throw `any Error`). I have personally found this sufficiently limiting that I've given up using typed throws in the few places I want to, for now.
In Problems with C++ exceptions> Can I now build my app in Xcode with an Android target and use that binary in the Play Store?
No. The vision document[1] lays out the direction of travel. Currently the focus is on shared business logic and libraries, rather than full native applications (although that's certainly a goal, albeit a very long term one).
[1]: https://github.com/swiftlang/swift-evolution/pull/2946/files
In The Swift SDK for AndroidOpt-In Strict Memory Safety Checking in Swift 6.2
5 points · Open discussionThey are actually working on that now with approchable concurrency[1].
[1]https://github.com/swiftlang/swift-evolution/blob/main/visio...
In Isolated(any)As long as the Obj-C and Swift are in separate source or binary targets, SPM supports them being in the same package.
There was a Swift Evolution proposal at one point to go all the way and bring in support for mixed Obj-C and Swift targets [1] but it was returned for revision. It talks about the multiple target workarounds:
> Distribute binary frameworks via binary targets. Drawbacks include that the package will be less portable as it can only support platforms that the binaries support, binary dependencies are only available on Apple platforms, customers cannot view or easily debug the source in their project workspace, and tooling is required to generate the binaries for release.
> Separate a target’s implementation into sub-targets based on language type, adding dependencies where necessary. For example, a target Foo may have Swift-o
Read the rest
nly sources that can call into an underlying target FooObjc that contains Clang-only sources. Drawbacks include needing to depend on the public API surfaces between the targets, increasing the complexity of the package’s manifest and organization for both maintainers and clients, and preventing package developers from incrementally migrating internal implementation from one language to another (e.g. Objective-C to Swift) since there is still a separation across targets based on language.
The upshot is that SPM has a better interoperability story with Swift and C++ [2] and maybe that can serve as a foundation for getting to the same level of interop for Obj-C.
[1]: https://github.com/swiftlang/swift-evolution/blob/main/propo...
[2]: https://www.swift.org/documentation/cxx-interop/
Sure, here are a few more examples:
- https://developer.apple.com/documentation/swift/tasklocal
- https://sosumi.ai/documentation/swiftui/button
- https://sosumi.ai/documentation/foundation/measurement
Most of the docs about the language itself live on swift.org (e.g. https://docs.swift.org/swift-book/documentation/the-swift-pr...). I've had pretty good luck getting Claude to write modern Swift code by saying things like "Use Swift 6 structured concurrency instead of GCD". But I could totally see expanding sosumi to include swift.org content, too.
Edit: Another Swift developer life hack: for new language features, copy-pasting the Swift Evolution proposal works pretty well! https://github.com/swiftlang/swift-evolution/tree/main/propo...
In Show HN: Sosumi.ai – Convert Apple Developer docs to AI-readable MarkdownReplying to your other comment.
> You are claiming that static code analysis tools extensively used in C++ cannot detect all conceivable and hypothetical memory issues. The weasel words in here is that it is possible to detect them, but some can conceivably slip through.
No, there are entire classes of memory vulnerabilities that are impossible to check with static analysis because checking them is equivalent to the halting problem.
> To drive the point home, there are already a few CVEs even from use-after-free bugs in Rust code. What does that make out of the all assertion? Would this be a reasonable argument to reject Rust as an unsafe language?
The CVE that you referenced in the other comment was Rust calling into unsafe C code, as I pointed out. If you have a real example feel free to post it.
> The problem with these claims is that
Read the rest
they rely on weak strawmen arguments and a very superficial analysis of the problem space. I get the need to do marketing, but if the audience is technical them don't you think arguments should stand on solid technical ground?
The views I have laid out here are the consensus among compiler engineers and in theoretical computer science. You only have to look at the compiler group at Apple:
- heavily invested in static analysis
- maintains the clang static analyzer
- maintains number of runtime memory analysis tools in Xcode
- not invested in rust at all and seemingly not interested
Yet they are adding lifetime dependency annotations to Swift, making it more like Rust: https://github.com/swiftlang/swift-evolution/blob/ef71df4158...
The reason for this is that static analysis simply cannot do it when the semantic information about lifetimes is lost, even for a group that knows how to write strong static analysis tools. Program flow is too ambiguous without it, so it becomes impossible to detect such memory vulnerabilities without running the program and fuzzing it – an expensive, time consuming, and probabilistic process.
There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/propo...
Tl;dr: Sequence and Collection are incompatible with noncopyable types and conditionally conforming when elements are copyable would result in too many implicit copies. They’re working on protocols to cover noncopyable collections such as this, which will probably have a similar API shape.
In What’s new in Swift 6.2Showing the 15 most recent of 154 sources. Enable JavaScript to search and browse every indexed mention.