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

111–120 of 258 posts

Re: What’s new in Swift 6.2

#111

Post by adamwk »

monkeyelite wrote: post #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…

There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/propo...

Tl;dr: Sequence and Collection are incompatible with noncopyable types and conditionally conforming when elements are copyable would result in too many implicit copies. They’re working on protocols to cover noncopyable collections such as this, which will probably have a similar API shape.

Re: What’s new in Swift 6.2

#112

Post by DidYaWipe »

"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. Gee, I've been told that a value changed in this object, so let's recalculate some stuff. WHOOPS, nope, none of the other objects (or hell, even the affected object) can take action yet because they can't interrogate the object for its new contents.

Truly incredible that they not only defaulted, but LIMITED change-detection to WILL-change, the least useful of the two choices.

Re: What’s new in Swift 6.2

#113

Post by rTX5CMRXIfFG »

bbatsell wrote: post #14
90s_dev wrote: post #7

Earlier quoted context omitted.

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 lo…

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 DS…

The HTTP status enum example is a _terrible_ one. If you need to represent HTTP statuses and call them by their integer names, why not just pass the damn integer itself? It's exactly what you get in `HTTPURLResponse.statusCode`, and you can already `switch` against it. Already not looking forward to the code that undiscerning devs will mindlessly write just because someone with a huge following wrote a blog.

Re: What’s new in Swift 6.2

#114

Post by [deleted] »

travisgriggs wrote: post #63

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…

[deleted]

Re: What’s new in Swift 6.2

#115

Post by wingerlang »

wsc981 wrote: post #73
Hashex129542 wrote: post #59

Mostly nonsense updates. Swift was my favorite programming language after C++/Java since 2014. I've been faced major updates few times happily. It was one of the most easiest language. But now, I tried to update a project from Swift 5.x to 6.x which has 150+ source files itself and no external libraries which is written by my own use and it has almost all swift 5.x features. They made up Swift as super hard. I decide…

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.

There is probably around a decade-long leap between XIB and SwiftUI. XIB files are only found in legacy code nowadays. It might have worked fine in smaller projects, but I think there are good reasons why it was left behind.

In my experience, most XIB files were either so small and easy that it was simply easier to replicate it in ten lines of code. Or so giant an impenetrable that it took thousands of lines of code to replicate it with, and at that point most people prefer to work with code over a dense XIB file.

Re: What’s new in Swift 6.2

#116

Post by saghm »

adamwk wrote: post #111
monkeyelite wrote: post #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…

There’s a section in the proposal about this: https://github.com/swiftlang/swift-evolution/blob/main/propo... Tl;dr: Sequence and Collection are incompatible with noncopyable types and conditionally conforming when elements are copyable would result in too many implicit copies. They’re working on protocols to cover noncopyable collections such as this, which will probably have a similar API shape.

Interesting; if I'm understanding correctly, it sounds like Swift doesn't have a standard lazy iteration API yet? I would have guessed that it did if asked before reading this, but it's good to hear that they're already working on it. Since I feel super spoiled by lazy iterators in Rust, I'm super curious if anyone has more Swift experience and could chime in on if there are other language features or APIs that might illuminate why there wasn't as much of a need for this earlier; my general perception of Swift as an outsider is that it tends to have pretty well-thought out decisions based on factors that I just happen not to know about personally (e.g. compatibility with other parts of the Apple software ecosystem or different priorities due to the domains Swift is often used in compared to the type of stuff I work on personally).

Re: What’s new in Swift 6.2

#117

Post by msie »

rcruzeiro wrote: post #86
elcritch wrote: post #76

Earlier quoted context omitted.

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

> Swift’s goals are great, I like the syntax, but the language implementation seems to just special case everything rather than having coherent language design. This could not be furthest for the truth. The entire process of proposing a new language feature to getting it implemented and shipped is out in the open for everyone to participate/see. https://github.com/swiftlang/swift-evolution

Too many cooks!

Re: What’s new in Swift 6.2

#118

Post by andrekandre »

ardit33 wrote: post #93

Swift is amateur hour in action by academics that don't value practicality. The new Concurrency was ill thought, and done by people that just perhaps either don't have enough practical experience, or are so enamored with the actor paradigm (erlang) that they had to shove it down the throat in a ecosystem where it is not used that much. No one is really using Swift for distributed programing. Glad they are backtrackin…

  > or are so enamored with the actor paradigm (erlang)
swift actors are barely actors in the erlang sense, not even close

maybe you're referring to structured concurrency?

Re: What’s new in Swift 6.2

#119

Post by wingerlang »

rcruzeiro wrote: post #79
90s_dev wrote: post #5

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

This is useful for testing. Currently, I need to write both the string name of the text and an identifier based on that name for the function itself. Soon I will only need to write it once. This is not much useful for much else though, and just because you can write code like this, it does not mean you should.

Why do you need both an identifier and a text? I have this test name 'testAddingNewCardDataResultsInProperlyCombinedCardDataButNoNewCardsUnlocksBecauseWeStillHaveUnlearnedCards', and even though it is much longer than my other ones, it is still perfectly readable, and even if it wasn't, the only time I actually have to read it, is if it fails.

Re: What’s new in Swift 6.2

#120

Post by jshier »

rcruzeiro wrote: post #91
afavour wrote: post #8

Earlier quoted context omitted.

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 cle…

Knowing which parts of Foundation will explode on your face on Linux is most of the challenge of doing non-Apple Swift code.

None, if you stick to using the bits from swift-foundation instead of swift-corelibs-foundation. Confusing, but the new code is much better, and in production on Apple's platforms as well.
Post reply on HN