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.
What’s new in Swift 6.2
241–250 of 258 posts
Re: What’s new in Swift 6.2
#242Earlier 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!
Although I still stress that it has never been an issue in Kotlin.
Re: What’s new in Swift 6.2
#243I'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.
(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
#244I'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.
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
#245Earlier 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.
Re: What’s new in Swift 6.2
#246Free-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…
Re: What’s new in Swift 6.2
#247I'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.
Re: What’s new in Swift 6.2
#248Earlier 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…
Re: What’s new in Swift 6.2
#249Earlier 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
Re: What’s new in Swift 6.2
#250Earlier 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…