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

Swift 5 Exclusivity Enforcement

swift.org

Post reply on HN
Print view View original

51–60 of 63 posts

Re: Swift 5 Exclusivity Enforcement

#51

Post by Buttons840 »

zozbot123 wrote: post #45
mamcx wrote: post #34

Earlier quoted context omitted.

Agree. Is similar on rust, where circular links are also hard to do. Easy graphs is a killer feature of a GC. But also, is a localized problem. I have more issues with obj-c in the past, some ergonomic of swift make it even rarer. However, certainly suck for the ones that hit this!. I'm building a relational lang in rust and damm, I miss a GC!

Many people in the Rust community use some sort of ECS in cases where something like a GC is needed. The whole point of ECS is that they work a lot like an ordinary GC runtime or an in-memory database, the underlying representation ensures that the system knows about all the "entities" that it needs to, and can reliably trace linkages between them. It might be easier to just use Go in cases where tracing GC is needed…

I've only heard of using ECS for games. I'll have to look into them more closely.

Re: Swift 5 Exclusivity Enforcement

#52

Post by bsaul »

ken wrote: post #20
bsaul wrote: post #8

Earlier quoted context omitted.

The examples are complex to follow because Swift model works just fine for all the normal cases. It only becomes problematic in some edge cases that regular programmer rarely meet. And with all the help that the compiler now provides (even before swift 5), it's becoming really really hard to shoot yourself in the foot.

I must be specially talented in this area, because I still run into memory issues fairly often. Just a couple days ago, I had a weak reference which was turning nil (Swift weak references are zeroing), and I couldn't figure out why. Both objects were still live. Property observers don't report the nil change, apparently. I couldn't figure out how to get the debugger or Instruments to provide any help, either. Eventua…

concurrency is still a work in progress for swift, so yes gcd still requires extra care to manipulate.

if you want to stick to a pattern, i recommend the actor pattern : create big objects that receive commands (as struct, not class) from any thread but immediately queue them in their own private queue to be processed serially.

That’s the most robust and no-brainer pattern, and the unofficial long term target for swift concurrency anyway.

You can use operation and operationqueue classes as building blocks.

Re: Swift 5 Exclusivity Enforcement

#53

Post by fauigerzigerk »

saagarjha wrote: post #6
kris-s wrote: post #4

I put Swift into the category of "almost memory managed" languages and it's never fully clicked in my brain. Thinking about strong/weak/unowned references is more difficult in my opinion than when to malloc/free something. Following the examples in the article just reinforced that maybe Swift's approach is a little too complex.

The benefit being that you only have to deal with this issue rarely, rather than all the time with manual memory management.

I find it extremely dangerous if issues arise rarely but not rarely enough stop thinking about them and not as rarely as you would think. Look at this terrifying example from [1]. How long do you have to look at this code to tell if there is a reference cycle or not?

    class ServiceLayer {
        // ...
        private var task: URLSessionDataTask?

        func foo(url: URL) {
            task = URLSession.shared.dataTask(with: url) { data, response, error in
                let result = // process data
                DispatchQueue.main.async { [weak self] in
                    self?.handleResult(result)
                }
            }
            task?.resume()
        }

        deinit {
            task?.cancel()
        }
    }
[1] http://marksands.github.io/2018/05/15/an-exhaustive-look-at-...

Re: Swift 5 Exclusivity Enforcement

#54

Post by richardwhiuk »

xenadu02 wrote: post #23
ken wrote: post #20

Earlier quoted context omitted.

I must be specially talented in this area, because I still run into memory issues fairly often. Just a couple days ago, I had a weak reference which was turning nil (Swift weak references are zeroing), and I couldn't figure out why. Both objects were still live. Property observers don't report the nil change, apparently. I couldn't figure out how to get the debugger or Instruments to provide any help, either. Eventua…

> I had a weak reference which was turning nil (Swift weak references are zeroing), and I couldn't figure out why This is extremely unlikely. If zeroing weak references were broken a lot of macOS/iOS would be broken. You probably have a bug or the memory just hasn't been overwritten yet, but the retain count is actually zero, you overwrote the reference, or something similar. Turn on Zombie Objects in Xcode then try…

Weak references turning nil is perfectly expected.

But you should never access a weak reference. When you need to access a weak reference, you should attempt to take a strong reference. That will either fail, and should be handled, or will succeed, and then will not be nil, and won't 'turn nil'.

Re: Swift 5 Exclusivity Enforcement

#55

Post by saagarjha »

fauigerzigerk wrote: post #53
saagarjha wrote: post #6

Earlier quoted context omitted.

The benefit being that you only have to deal with this issue rarely, rather than all the time with manual memory management.

I find it extremely dangerous if issues arise rarely but not rarely enough stop thinking about them and not as rarely as you would think. Look at this terrifying example from [1]. How long do you have to look at this code to tell if there is a reference cycle or not? class ServiceLayer { // ... private var task: URLSessionDataTask? func foo(url: URL) { task = URLSession.shared.dataTask(with: url) { data, response, er…

I think the "catch" is that dataTask will retain self? Yeah, I agree that capture semantics with closures is a bit complicated to get right.

Re: Swift 5 Exclusivity Enforcement

#57

Post by diegoperini »

kris-s wrote: post #4

I put Swift into the category of "almost memory managed" languages and it's never fully clicked in my brain. Thinking about strong/weak/unowned references is more difficult in my opinion than when to malloc/free something. Following the examples in the article just reinforced that maybe Swift's approach is a little too complex.

Looking from a distance, what Swift does is actually taking best practices from modern C++ (14+) and incorporating them on the language level instead of introducing new library tools.

If you regularly code C++, the "fuck, yes!" moment is there when you learn Swift.

Re: Swift 5 Exclusivity Enforcement

#58

Post by zozbot123 »

diegoperini wrote: post #57
kris-s wrote: post #4

I put Swift into the category of "almost memory managed" languages and it's never fully clicked in my brain. Thinking about strong/weak/unowned references is more difficult in my opinion than when to malloc/free something. Following the examples in the article just reinforced that maybe Swift's approach is a little too complex.

Looking from a distance, what Swift does is actually taking best practices from modern C++ (14+) and incorporating them on the language level instead of introducing new library tools. If you regularly code C++, the "fuck, yes!" moment is there when you learn Swift.

You're actually describing what Rust is doing, more than anything. Swift has a lot more in common with Objective-C than C++, even though it does move away from the most challenging parts of Objective-C itself.

Re: Swift 5 Exclusivity Enforcement

#59

Post by gurkendoktor »

diegoperini wrote: post #57
kris-s wrote: post #4

I put Swift into the category of "almost memory managed" languages and it's never fully clicked in my brain. Thinking about strong/weak/unowned references is more difficult in my opinion than when to malloc/free something. Following the examples in the article just reinforced that maybe Swift's approach is a little too complex.

Looking from a distance, what Swift does is actually taking best practices from modern C++ (14+) and incorporating them on the language level instead of introducing new library tools. If you regularly code C++, the "fuck, yes!" moment is there when you learn Swift.

The flip side is that Swift has copied some bad parts of C++ as well: ridiculous compile times, value-type performance traps, ever-increasing complexity, mediocre IDE support, no ABI (I know, coming soon).

Either way, to me Swift feels much closer to C++ than to Objective-C in spirit. I don't think it's a coincidence that there are at least two C++ committee veterans among its contributors :)

Re: Swift 5 Exclusivity Enforcement

#60

Post by fauigerzigerk »

saagarjha wrote: post #55
fauigerzigerk wrote: post #53

Earlier quoted context omitted.

I find it extremely dangerous if issues arise rarely but not rarely enough stop thinking about them and not as rarely as you would think. Look at this terrifying example from [1]. How long do you have to look at this code to tell if there is a reference cycle or not? class ServiceLayer { // ... private var task: URLSessionDataTask? func foo(url: URL) { task = URLSession.shared.dataTask(with: url) { data, response, er…

I think the "catch" is that dataTask will retain self? Yeah, I agree that capture semantics with closures is a bit complicated to get right.

Yes, dataTask will retain self in spite of the fact that [weak self] is used in the only place where self is explicitly referenced. This is baffling.

After reading the linked article I have come to think that reference counting is not a good fit for a language that mixes object orientation with functional idioms including tons of closures.

Post reply on HN