@krzyzanowskim@heckj threading was always fraught with mistakes, we were just living blissfully unaware and blaming random instability into “I guess we will never know”
@Migueldeicaza@krzyzanowskim Speaking truth. The benefits of the compiler guarantees are amazing - with them in place, I spotted issues that I thought were otherwise completely safe, patterns of doing things that "just worked" 99.9% of the time because I wasn't unlucky. This is a huge update to pressing forward on writing solid, reliable code.
@Migueldeicaza@krzyzanowskim@heckj it’s because the type of the global variable is not Sendable. Initialization of globals is thread-safe, but if the value has, say, reference types with mutable state, then you can still get concurrent mutations.
@holly@krzyzanowskim@heckj thank you Holly, I didn’t know what the rules were for that and made myself a test case earlier for the global. Glad to know that step is expected!
@Migueldeicaza@krzyzanowskim@heckj assuming this is a global variable, Swift let values are lazy initialized when they're global. So any thread could potentially be the first one to read it and thus initialize it the same moment another thread tries to read it and thus initialize it.
@krzyzanowskim@bigzaphod@Migueldeicaza@heckj but your synchronous code that accesses/initializes the value could be called on any thread—unless you have some synchronization mechanism
@krzyzanowskim@bigzaphod@Migueldeicaza@heckj you don't, but presumably there's some synchronous entry point into your code that could be invoked on any thread, so transitively the let initializer could be invoked on any thread:
the compiler doesn't actually do that level of flow analysis (so far as I know), but it makes the assumption that that scenario exists because it can't prove otherwise
@krzyzanowskim@bigzaphod@Migueldeicaza@heckj the compiler doesn't know that the codepath exists. it just can't prove that the codepath doesn't exist. if you can make that guarantee, then you can use nonisolated(unsafe)
@krzyzanowskim@shadowfacts@bigzaphod@heckj his example shows the race, the external caller influences this. You might not like it, but it is catching a real problem :-)
@krzyzanowskim@Migueldeicaza@bigzaphod@heckj it could be accessed from a different thread than it was initialized on, so it needs to be either Sendable (letting the compiler prove that's safe) or it needs to be nonisolated(unsafe) (telling the compiler that you are guaranteeing it's safe).
I'm not saying blindly slapping @MainActor on things is the best solution—here it looks like CS.BigUInt should be Sendable
@krzyzanowskim@Migueldeicaza@heckj unless something is isolated to a specific actor somewhere, I think the compiler's assumption is that all actors are potentially able to use anything anywhere and so it warns about stuff. It's annoying for sure. It has seriously harmed the learnability of Swift. It drives me crazy. I'm just saying... this is why it's telling you that - not that I agree with it or that it couldn't do a better job being smart.
@titociuro@krzyzanowskim@heckj I see it the other way around, I won’t spent countless hours tracking down a nasty and irreproducible bug, which have done more times than I would have ever wanted in my life.
@Migueldeicaza@krzyzanowskim@heckj The thing is… I just haven’t suffered that many cases like you describe. Sure! Some, but I honestly had a pretty good grasp on GCD. Crashes are rare and far between. So spending all this time adopting SC is not productive. Let alone fun. 🤷🏻♂️
@Migueldeicaza@krzyzanowskim@heckj Yeah, right. 🙄 I love your work, and I think it’s more complex than the average iOS app. While SC will help you conquer those daemons, I think it’s overkill for most apps. I dunno… I must be old school, but I sure feel more comfortable with GCD.
@titociuro@Migueldeicaza I'm in that transitional area where I learned both GCD and SC, but I can see both sides. There's a nice simplicity to GCD that "just works". At the same time, SC follows up on Swift's explicit philosophies, and I do feel it has its place as a language-wide concurrency solution (I think GCD is Apple-specific, last I checked). So I can't really say one is better than the other, but I can say both opinions are valid.
@me@titociuro anecdotally, every time I go “I know perfectly well that this can never be nil, so I can safely do “x!.foo”, some months later I get a crash report because someone managed to make the x a nil in production.
Add comment