Live data from Hacker News

What’s new in Swift 6.2

hackingwithswift.com

241–250 of 258 posts

Re: What’s new in Swift 6.2

#241
post #221

Earlier quoted context omitted.

From the FAQ… > Skip supports both compiling Swift natively for Android, and transpiling Swift into Kotlin. Read about Skip’s modes in the documentation. https://skip.tools/docs/faq/#modes

Yes, it transpiles a Swift+SwiftUI codebase into a Kotlin+Compose codebase. I don’t want that intermediary step, I want the Swift itself running on Android.

> Skip supports both native mode - in which your Swift is compiled natively for Android - and transpiled mode - in which your Swift is converted to Kotlin. The mode is specified at the level of a Swift module. Each mode has strengths and weaknesses, and it is common to use both native and transpiled modules within a single Swift-on-Android app.

https://skip.tools/docs/modes/

Re: What’s new in Swift 6.2

#242
post #66
post #51

Earlier quoted context omitted.

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.

Wow, you are correct! A Rust "raw identifiers" can be a reserved keyword. But other than that, all other normal identifier naming rules still apply... And apparently I never figured this out even after 3 years of Rust lol, thanks!

Whoops, I had an edit that apparantly did not submit. My comment is very wrong now, the only language in that list that supports "raw identifiers" in the same sense as Swift is Kotlin.

Although I still stress that it has never been an issue in Kotlin.

Re: What’s new in Swift 6.2

#243
post #56

I've been starting to use Swift again lately after like four years, and while the language is beautiful & the package management story is now a LOT better with SwiftPM, I found that none of it plays nicely with XCode, Simulator, or anything to do with iOS/macOS development -- its primary use-case! I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iO…

I'm confused. You said "none if it plays nicely with Xcode" but then you complain about what the experience is like when not using Xcode.

As far as I could tell, if you create a Main.swift file, you can't just open that in XCode and start running it as an iOS/macOS application, and instead have to create a .xcodeproj/.xcworkspace through XCode, and add your Swift to the scaffolded project - this seems backwards to me.

(I then separately complained at all the steps it took to get it running without XCode, as I didn't want to be locked into using it)

Re: What’s new in Swift 6.2

#244
post #56

I've been starting to use Swift again lately after like four years, and while the language is beautiful & the package management story is now a LOT better with SwiftPM, I found that none of it plays nicely with XCode, Simulator, or anything to do with iOS/macOS development -- its primary use-case! I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iO…

You are talking about the language but bringing up an example of creating an app for an Apple platform. Regardless of the language you will have to create app bundle structure, copy assets inside, add mobile provision and sign it. If you ask me, those platform specific things should never be integrated part of the language.

Sure, but developing for Apple's platforms is Swift's primary use. I'd say Dart & Flutter is a fair comparison:

As flawed as they are in my eyes, its dev tooling quality is something I appreciate and wish I saw here. There are two CLIs, one for the language (Dart) and one for the framework (Flutter). Some would say that the CLI equivalent would be xcodebuild, but that depends on the complex .xcodeproj/.xcworkspace structure and still requires XCode to be installed.

Re: What’s new in Swift 6.2

#245
post #145
post #94

Earlier quoted context omitted.

It is not just the language but the frameworks. SwiftUI is a wreck, and still not mature even after 6-7+ years in 'production'. You still have to drop to UIKit to do advanced UI, and for what it is, SwiftUI is just not practical enough for cases that are not trivial. The trouble is that all new kids/engineer are learning it first, which means software wont get better. Apple need to improve it first, and I don't see a…

What baffles me the most is testability of SwiftUI. It simply does not exist.

This is true, I wonder what Apple uses internally to test SwiftUI.

Re: What’s new in Swift 6.2

#246
post #29

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 create a bug. It's less of a problem with semantic names. If you want constrained numeric types in Swift,…

> Just use semantic names like `HTTPStatus.NotFound` and you wouldn't have a problem in the first place. Have to disagree there: when I tried re-implementing a basic websocket server in multiple languages ( https://news.ycombinator.com/item?id=43800784 ), I found it so frustrating when they'd insist on hiding the raw close-codes behind pretty names, because it meant having to stop what I was doing to jump into the do…

If you don’t want to deal with that, you can just use the number. Some APIs have integer overloads for that purpose, but you can also typecast. I don’t find HTTPStatus.`1003` more helpful than 1003.

Re: What’s new in Swift 6.2

#247
post #56

I've been starting to use Swift again lately after like four years, and while the language is beautiful & the package management story is now a LOT better with SwiftPM, I found that none of it plays nicely with XCode, Simulator, or anything to do with iOS/macOS development -- its primary use-case! I found myself awestruck that I *HAD* to use XCode or xcodebuild, and could not just run `swift build` and generate an iO…

I'm confused. You said "none if it plays nicely with Xcode" but then you complain about what the experience is like when not using Xcode.

Not op, but I think "doesn't play nicely" means does not work so you have to do it in other ways. This has been my experience as well, albeit it was couple of years ago.

Re: What’s new in Swift 6.2

#248

Earlier quoted context omitted.

Just curious, but would it have been feasible to update the Objective-C compiler to reduce these pain points? Or was there issue more intrinsic to the design of the language itself?

With the caveat that I’m not all that knowledgeable about compilers, as I understand it, no not really. The compiler’s “reasoning” about types is extremely rudimentary and is easy to “deceive” because like a C compiler, it trusts that the dev knows what they’re doing. This can enable an experienced vet to move quickly due to low resistance, but makes the occasional slipups that even vets commit easy to miss. You’d ba…

Thanks for this! More or less what I expected, just wanted to be sure.

Re: What’s new in Swift 6.2

#249
post #231
post #224

Earlier quoted context omitted.

You want to exhaustively handle all 500 valid HTTP status codes (cf. RFC 9110)?

Exhaustive matching doesn’t necessarily mean you handle every case separately, but it means you aren’t going to get cases you don’t know about sneaking in. With a bare int you can get values outside a range and the compiler won’t help

Either you’re unaware or you’re arguing in bad faith, but you can switch against integers and pattern-match within integer ranges. The consequences of receiving an unexpected status code is the same—you handle it in the default case, as you would when decoding to an HTTPStatus enum fails.

Re: What’s new in Swift 6.2

#250
post #127

Earlier quoted context omitted.

Cool. I was smitten with Scala for a while but it was getting too complex after a while. Like Swift and C++.

I think it's genuinely simpler than Swift or Kotlin that have seen an explosion of grammar, keywords and features. The modern Scala ecosystem has mostly converged towards one style even though it's fully compatible with the more questionable Java/JVM constructs like runtime reflection, annotation processing and so on. Sure you have to understand a few FP concepts that might be alien at first, but there's a fairly str…

I tried Scala a long time ago, and although I don't remember much about it, I do remember that it felt like Perl for Java. If that's accurate, then it may not have syntactical complexity, but only because it moves that complexity into semantics.
Post reply on HN