What's New in Swift 6.2?
51 comments
·May 9, 2025w10-1
strongpigeon
Agreed about Paul Hudson. He also just seems like a genuinely nice guy. I was kind of shocked to receive an email from him out of the blue last weekend (well, from GitHub, but with his name in the "From" field). Turns out it was about a PR [0] to one of my packages where he fixed typos in the README.
sedatk
Free-form identifiers are neat for test-case naming, but not for `HTTPStatus.`404``. I think having `HTTPStatus.Error404` was a bad idea to begin with. Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Now, a single character typo can easily make a 404, 403 and easily create a bug. It's less of a problem with semantic names.
If you want constrained numeric types in Swift, that's another problem to tackle. But `HTTPStatus.`404`` seems to be the least ideal way to go about it. It lets you do stuff like to declare `HttpStatus.`404`` with a value of 403 too.
trevor-e
Lot of nice improvements here. I'm actually quite liking the async API after using it in a couple small apps and learning the fundamentals.
I really wish the entire Swift team would spend a quarter fixing bugs and improving the compiler speed, though. So many trivial SwiftUI cases trigger the "this is too complex for the compiler" errors which are so frustrating to fix.
amichail
Do you try to put everything on the main actor to dramatically reduce your debugging time?
trevor-e
Main actor by default is a decent strategy. It's usually pretty obvious when something needs to happen off the main actor.
favorited
Especially in apps, where most of the code will be about preparing the user interface and handling events. And it's relatively easy to make most lower-level components actor-agnostic – either by making them conform to Sendable, by making them actors, or by giving them their own internal synchronization.
hn-acct
Everything probably already is or should be
90s_dev
> So, rather than writing > > @Test("Strip HTML tags from string") func stripHTMLTagsFromString() {...} > > we can instead write > > @Test func `Strip HTML tags from string`() {...}
Maybe I'm just really new at programming, but this seems like an absolutely bad feature, and the example actually perfectly proves it:
You really want to name a function "Hello World!" instead of helloWorld, just so your stack traces can pass a 5th grade English class exam?
90s_dev
It just seems to me that this is the exactly wrong way to solve a programming problem. If the problem boils down to "I want some variables (almost always test function names) to be more human readable", the solution should never be "hey let's add this feature to the core language and make identifiers use any ASCII string! I dunno, maybe I'm wrong here and being overly critical. But to me it just screams "Swift has lost the plot."
null
nulld3v
Many languages have had this feature for a long time. Ruby, Rust, Kotlin, etc... It hasn't been an issue at all.
I like that most languages seem to have reached consensus on backticks or other similarily awkward characters for this feature. Typing these identifiers is like hitting a speed bump, which seems to be enough to make devs avoid them except for very specific use-cases.
0rzech
Rust does not have this feature. Function names can't have spaces, for example. Underscores are used instead. Maybe there are some macros for arbitrary ASCII strings - I don't know - but it's not a language feature.
bbatsell
The HTTPStatus enum example is a good one, but the backtick syntax is _rough_. I would only ever use the Type.case form in practice. The test stuff is basically a way to create BDD-style test names, which is kind of just a preference thing. I can’t envision myself using it for anything other than weird case names (I already use case `default` quite a lot because it’s such a useful word), but maybe some interesting DSLs can come out of it? I would not have prioritized that change personally.
90s_dev
I would not have even approved it. But that's just me.
seanmcdirmid
Tests are never called explicitly by programmers, or at least they never should be. You could argue that they don’t really need to be functions at all, just pieces of code that represent tests.
SwiftyBug
That's how Zig tests work. This is basically a function with a different syntax.
test "strip html tags from string" {
...
}soegaard
The feature is fine but there are better reasons to introduce it.
For macro generated code it is convenient to use identifiers that people won't accidently use in their own code. The ability to use arbitrary identifiers solve that.
int_19h
The other reason is interop with other languages, which might have their own rules for identifiers.
codr7
Except people can also use arbitrary identifiers in their own code now?
thedanbob
I don't know about other languages but Ruby is similar in that you can name a function with any string (though you might not be able to call it in the standard way) and the Rails default test framework takes advantage of that.
Jtsummers
https://tio.run/##S87JLC74/18jJTWtNE@hJiM1JydfoTy/KCelRkFDk0...
Common Lisp allows it as well, though I don't think I've ever seen it done outside a demonstration that it can be done.
hiccuphippo
Naming things is hard. If you can more accurately describe your test and not think of a separate name for it I'm all for it.
Also I like the backticks better than what zig came up with: @"404"
null
codr7
There's a lot I love about Swift, but I fear it's quickly becoming too complicated for its own good.
There are just so many ways to solve a problem now that it's more or less impossible for someone to be familiar with all of them.
favorited
Many of these features have convoluted-sounding names like "global-actor isolated conformances" or "control default actor isolation inference," but they are changes that make actually using the language simpler.
People aren't expected to really learn that there is a "feature" called global-actor isolated conformances, but at some point they'll try to make a UI type conform to `Equatable,` and instead of an error saying you can't do that, they'll get a fixit about needing to specify the conformance as `struct MyUIType: @MainActor Equatable` instead.
I bet 99% of codebases won't use "method and initializer key paths," but there's really no reason why you should be able to get a key path to a property, but not a method. It just hadn't been implemented yet, and the language is more consistent now.
Personally, I think raw identifiers are kinda dumb, but that just means I won't use them. IMO there isn't really more cognitive overhead when using the language because it's possible to use spaces in function names now.
arecurrence
I too wish deprecation with migration path was a more common pattern in today's language development. The language has very much needed work and the numerous bugs within Apple's own libraries certainly hasn't helped.
That said, some of the, erm, "new ways" to solve problems have been significant advancements. EG: Async/Await was a huge improvement over Combine for a wide variety of scenarios.
storoj
IMO async/await and Combine are two completely different things.
What is the alternative to Combine's CurrentValueSubject or combineLatest()?
90s_dev
So it's becoming C++?
codr7
That's my feeling, and it makes me sad because I have largely given up on C++ for that reason.
hirvi74
Considering Swift was primarily written in C++, perhaps Swift was always destined to follow the same path?
amichail
Is having too many ways to solve a problem an issue for solo indie developers?
null
90s_dev
I have not looked at Swift since I last wrote some around maybe v3. I hear that it's generally not a competitor to Rust, and is only really useful within the Apple ecosystem. Why is it not more useful as a C++ alternative, since I think that's kind of what the initial goal was? Is it just that non-Apple support is new-ish and not yet matured? Or a more fundamental issue?
porcoda
I use it as a C++ alternative on Linux. We ported a substantial code base from C++ to Swift last year and it works great. Performance is better in some places, comparable to C++ in others. Productivity is definitely improved over the C++ codebase. We didn’t use rust for this project after evaluating how that migration would impact how it was designed internally, and we decided it wasn’t the right way to go. I think the “swift is only relevant in apple ecosystem” view is inaccurate these days. Swift certainly isn’t the answer to every project, just like rust or any other language isn’t the universal answer to every project. It’s worth considering though if it is appropriate.
afavour
There’s a level of self fulfilling prophecy here: people don’t use Swift off Apple platforms because there isn’t a critical mass of people using Swift off Apple platforms.
But that said it can be frustrating. A lot of the documentation and tutorials you find out there assume you’re on an Apple platform where, e.g. Foundation APIs are available. And the direction of the language, the features being added etc, very clearly serve Apple’s goals.
(Side note: IBM was an early adopter of Swift off-platform but then stepped back: https://forums.swift.org/t/december-12th-2019/31735)
jonny_eh
Apparently Arc Browser is written in Swift: https://www.reddit.com/r/ArcBrowser/comments/18j39g3/why_arc...
briandear
Generally only useful within the Apple ecosystem is definitely inaccurate.
An example: https://vapor.codes/
The problem is that people only think it’s generally useful in the Apple ecosystem.
ackfoobar
I don't use Swift not because I think it's not useful outside Apple, but because I believe its developer experience is poor. Some stories that formed my opinions:
https://news.ycombinator.com/item?id=9947193
https://news.ycombinator.com/item?id=42803489
Granted, my perception may be wrong, but trying it to know for sure costs time. Swift has not earned my time investment.
AnishLaddha
what advantages does swift offer over go/rust/js/java for server side programming? I always presumed the advantages of swift were native code compilation + top tier integration w/the apple ecosystem.
madeofpalk
In my little usage of it (and go and rust), Swift feels like a nice middleground between go and rust. Or, a better (safer) go.
I think Swift is vastly underestimated due to it's relation to Apple.
favorited
I have a few personal and professional Swift on server projects, in the wild and in the works. Code reuse is a big win – we can ~easily expose functionality of our client apps to other systems. Familiarity is another – there's an ocean of iOS (and, to a lesser extent, macOS) developers out there who are familiar with Swift. With a little bit of coaching, they can pretty quickly get up to speed with how services work.
It reminds me a lot of what it was like to ship Node.js software 15 years ago – the ecosystem is still young, but there are enough resources out there to solve 95% of the problems you'll face.
amichail
It's a high level language that doesn't get in your way.
725686
The advantage is obvious if you already use Swift.
null
pkulak
You can't really say a language with a garbage collector (Swift) is an alternative to one without (Rust, C++, etc), because a lot of the time, the reason someone is using a non-GC language is because they don't want a GC.
EDIT: Yes, ref. counting is garbage collection, before the replies blow up. haha
The article doesn’t give enough attention to the glacial but steady changes in the ownership model that will have great benefit in avoiding copies in value types, Swift’s strength and Achilles heel.
I have to say Paul Hudson has almost single-handedly taken over communicating the essentials of Swift to the world; he’s fantastically reliable, brief but enthusiastic, guiding people around the many pitfalls.