Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What’s new in Swift 6.2

hackingwithswift.com

Post reply on HN
Print view View original

251–258 of 258 posts

Re: What’s new in Swift 6.2

#251

Post by hocuspocus »

90s_dev wrote: post #250
hocuspocus wrote: post #203

Earlier quoted context omitted.

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.

Scala doesn't have operators (as in, + - * / ++ -- ... are just methods) and at some point library authors went a little overboard with DSLs using symbolic names, especially for concepts coming directly from Haskell. But those days are mostly over.

The type system is very powerful and a few concepts have complex semantics, there's no way around it. But in my experience what really hurt inexperienced developers is the mix and match of Java constructs and more functional or Scala specific ones. And in my opinion, the Kotlin ecosystem is even a bigger offender nowadays, while best practices in Scala have somewhat converged, as a direct consequence of its decline in popularity, i.e. because people have stopped trying to use Scala as a better Java.

Re: What’s new in Swift 6.2

#252

Post by dagmx »

rTX5CMRXIfFG wrote: post #249
dagmx wrote: post #231

Earlier quoted context omitted.

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.

Way to start of the comment by being uncivil. You could have made the exact same point without being a jerk about it.

But it’s common to only want to support specific response codes in a context, and people do use enums for that. It’s a fairly common paradigm, and an enum will do all those validations for you so you don’t forget.

Re: What’s new in Swift 6.2

#253

Post by Defletter »

sedatk wrote: post #246
Defletter wrote: post #202

Earlier quoted context omitted.

> 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.

Many of the languages/platforms/libraries that I used (eg: Bun) do not provide any kind of named-constant for this reason: just type 1003. But the value of named constants is that you can attach documentation to them.

To clarify something I said earlier, I would rather have to stop what I'm doing to look at documentation (something that can be done within the IDE) than have to open up a browser and read through the specification to figure out what some magic-value means. Having a provided named-constant that tells me what 1003 means is very useful for me and for other maintainers or contributors to the project, and it can link to the spec for more information anyway. Just having raw magic-values is not great for maintenance. Likewise, having pretty names entirely detached from the actual close-code makes searching for places where that close-code is used much harder. Even just "1003_REFUSE" or "1003_CANNOT_ACCEPT" is so much better.

Re: What’s new in Swift 6.2

#254

Post by hombre_fatal »

deergomoo wrote: post #182
eptcyka wrote: post #177

Earlier quoted context omitted.

No one tests multi-user functionality, afaict.

It’s insanely buggy. My wife has two user accounts, one for her work and one for everything else, so she can switch out of the work user at the end of the day to put it out of her mind. She comes across bugs on the regular that I’ve never seen in 16 years of Mac use, but only when the other user account is logged in (i.e. quick user switching rather than a full log out). Stuff that user accounts shouldn’t even make a…

I created a new user on my macbook for my girlfriend when her laptop broke, and she could see my files in the “Recent files” tab. I’m not even sure if there was a separation of files. And I have no clue what the intended boundary is supposed to be between users.

I made a new user for Zoom screen share and was equally confused when my personal files and info would show up in searches and such. And it seems like most things install globally?

Ended up using a whole new computer to have a clean screenshare environment.

Re: What’s new in Swift 6.2

#255

Post by marcellus23 »

catapps wrote: post #243
marcellus23 wrote: post #126

Earlier quoted context omitted.

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)

Oh — actually you can create a Swift package and open it with Xcode. You don't need an explicit xcodeproj or xcworkspace.

Re: What’s new in Swift 6.2

#256

Post by DidYaWipe »

viktorcode wrote: post #197
DidYaWipe wrote: post #112

"a new Observations struct that is created with a closure, and provides an AsyncSequence that emits new values whenever any any @Observable data changes" Is this another asinine onChange()-style mechanism that actually means WILL change? In other words, it tells you BEFORE the value is set on the object, so you can't do jack squat with it much of the time. That's the M.O. of onChange now, which is utterly brain-dead.…

> Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change That's not strictly true. You get the new value inside the closure. This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI. Before you had to write the code like this to achieve that: func startObservation() { withObservationTracking { print(store.state.toggle) // Here we have the n…

I know that you get the new value; but in many cases (almost every case I encountered), that doesn't help. You mention

"This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI"

I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.

For example, if I have an object that represents a camera, and the user tweaks a value in the UI that changes its resolution, the camera might offer a different set of values for things like frame rate.

So if I get notified that the user changed the resolution, I can't then tell the Recorder object to recompute the remaining recording time based on the camera settings, because those settings will not have changed yet.

And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.

It's another great example of serving only the most illogical and obscure use case. Who the hell would expect something called "startObservation" to just quit after one change? The stupidity is just galling.

Re: What’s new in Swift 6.2

#258

Post by viktorcode »

DidYaWipe wrote: post #256
viktorcode wrote: post #197

Earlier quoted context omitted.

> Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change That's not strictly true. You get the new value inside the closure. This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI. Before you had to write the code like this to achieve that: func startObservation() { withObservationTracking { print(store.state.toggle) // Here we have the n…

I know that you get the new value; but in many cases (almost every case I encountered), that doesn't help. You mention "This is very useful for observing changes on data model that drives SwifUI from outside of SwiftUI" I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, beca…

> And incidentally, I've used startObservation() in places, and it's crippled by another idiotic design choice: It only works once. It reports the first change, and then never another one. So in the onChange closure, you have to re-start the observation. Every goddamned time.

The restart is there in my example, and it doesn't look too complex. And this aspect of observation is exactly what will be changed in Swift 6.2. Nice improvement, I'd say!

> I disagree, because the model hasn't changed yet. That's the crippling aspect to it: You can't tell some controller object to recompute its state based on a change to another object in the model, because you're getting notified BEFORE that object has changed.

If your model stores 2 interdependent states then you'll risk running into infinite update loop regardless of whether you've been notified from `didSet` or `willSet`. It can be fixed by changing the model.

To be fair I didn't understand your example with camera and resolution. In all cases you already know the new value and so the dependent code is good to go. The code shouldn't ever care where the value comes from: the main state, the future state, or some mock state.

Post reply on HN