Live data from Hacker News

What’s new in Swift 6.2

hackingwithswift.com

101–110 of 258 posts

Re: What’s new in Swift 6.2

#102
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,…

> case _401 or case error401.

I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.

Re: What’s new in Swift 6.2

#103

Honest question. Not trying to troll. One of the pitches in the earlier days was “C/Objective-C OK, but you can’t write safe/next level code with it—-Swift will close that gap.” N years later, it doesn’t feel like there has been a step change in Apple software quality; if anything Apple software feels less solid, and looks cool “look what I did” extension points. I mean, some of the tings you could do with runtime ca…

As someone frequently flipping between Swift and Kotlin, while I don’t necessarily feel like Swift is massively superior, I often find myself thinking “why is this so quirky and pedantic” when writing Kotlin.

For example, I really really wish Kotlin would adopt Swift style if let/guard let statements. Kotlin smart casting doesn’t work just often enough to not be able to consistently rely on it and the foo?.let { } syntax is ugly.

Combined with the JVM warts of gradle and jankiness of code stripping and obfuscation, generally speaking if I could opt to use Swift in place of Kotlin for Android dev I would do so in a heartbeat.

Re: What’s new in Swift 6.2

#104
> InlineArray does not conform to either Sequence or Collection

Why not? Does this mean I need to make a struct which wraps InlineArray and implements Collection? Why didn't they do that?

EDIT: found the answer (I still have concerns):

> While we could conform to these protocols when the element is copyable, InlineArray is unlike Array in that there are no copy-on-write semantics; it is eagerly copied. Conforming to these protocols would potentially open doors to lots of implicit copies of the underlying InlineArray instance which could be problematic given the prevalence of generic collection algorithms and slicing behavior. To avoid this potential performance pitfall, we're explicitly not opting into conforming this type to Sequence or Collection.

Re: What’s new in Swift 6.2

#105
post #67
post #2

Do you try to put everything on the main actor to dramatically reduce your debugging time?

I can’t speak to swift, but in experience with many other langs and runtimes I will say that single-threaded business logic by default is still the only sane choice even today. There are exceptions both on client and server side, but you get so incredibly far with one thread, while eliminating so many potential bugs, that it’s borderline whether parallelism should even be exposed to application developers at all. Eve…

Absolutely - the idea of threads haphazardly interacting, like 2002 Java, is a terrible default assumption for designing languages and libraries.

It's not even clear the perf gains are great. Everything locking all the time has killed a lot of performance.

Re: What’s new in Swift 6.2

#106
post #73

Earlier quoted context omitted.

I find 'simple' languages charming. Hence, I still like Objective-C. I also like Lua a lot. I liked Swift when I tried it a couple of years ago, but it seems overloaded with features these days. I haven't tried Swift UI yet, but I did think the Objective-C approach with xibs, struts and such worked fine.

xibs were an absolute nightmare if you worked with a team. Even in the Objective-C days a lot of developers were sticking with programatic layout to avoid xibs. Google even had this mandated in their Objective-C style guide.

On iOS, code-only UIKit with bits of SwiftUI interspersed for simple components (think collection view cells) is definitely the way to go. UIKit is well equipped to be written that way (unlike Android Framework, which practically forces use of XML layouts in many cases).

For Mac dev, AppKit is still fairly heavily weighted towards use of XIBs, but it’s not nearly as much of an issue there because on average each individual XIB isn’t as overloaded with controls because the UI is more split up.

Re: What’s new in Swift 6.2

#107
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,…

You might mess up 403 vs 401 in this system, but then in the next system you're messing up Unauthorized vs Forbidden. It's like when you see a poisonous snake and can't remember if "red touches yellow" is paired with "deadly fellow" or "friendly fellow".

Messing up Unauthorized vs Forbidden is a semantic problem, but 403 vs 401 can be either semantic or syntactical. It’s not like you’d mispress a key and get Forbidden instead of Unauthorized.

Re: What’s new in Swift 6.2

#108
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,…

> case _401 or case error401. I'm not seeing why it's worth a whole language feature to avoid prefixing strange identifiers.

I don’t think it’s the sole reason, but I find that example odd for sure.

Re: What’s new in Swift 6.2

#109
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,…

Yeah, this feature seems wholly unnecessary and possibly dumb. The example given is ridiculous.

If you can't figure out what stripHTMLTagsFromString() does, you have way bigger problems than a lack of spaces.

Re: What’s new in Swift 6.2

#110

Honest question. Not trying to troll. One of the pitches in the earlier days was “C/Objective-C OK, but you can’t write safe/next level code with it—-Swift will close that gap.” N years later, it doesn’t feel like there has been a step change in Apple software quality; if anything Apple software feels less solid, and looks cool “look what I did” extension points. I mean, some of the tings you could do with runtime ca…

I feel the same. Apple software quality certainly hasn’t increased . Years back I remember some apps crashing suddenly after updating MacOS. I checked the binary and saw they’d started adding Swift. Half a decade later it seems like it should be better and Swift stuff should be stabilized. But nope, I’ve had more little glitches in both iOS and MacOS. It’s hard to say it’s due to Swift, and not management priorities.…

I have a good bug right now. My wife bought a Macbook Air. I use High DPI and she does not. It is impossible to switch between users in this situation, one of the core functionalities of the computer is just broken. Makes me wonder if anyone at Apple uses these computers..
Post reply on HN