Introducing the @ stfu macro, your one stop shop for fixing all your concurrency problems. See an error full of words you don't understand like sendable, non-isolated, sending, data race, shared mutable state? Simply tag your code with @ stfu and watch the errors disappear™️!
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
the region based isolation checker isn't real it can't hurt you
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
Don't want to pile on to the criticism too much, but concurrency just feels broken in Swift 6. Why would passing a CGFloat across threads cause a data race? Swift 6.1 tells me it's actually previewLayer that causes the issue. I wanted to at least try to avoid future concurrency issues, but that's pretty hard when the compiler is just wrong.
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees This is very good/very bad
=> More informations about this toot | More toots from mattiem@mastodon.social
@finnvoorhees Have you tried the 6.1 branch here?
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem It seems like that might have fixed it.
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees I’ll wait until Swift 5.9 is deprecated.
=> More informations about this toot | More toots from dasdom@chaos.social
@finnvoorhees This is a bug
=> More informations about this toot | More toots from mattiem@mastodon.social
@finnvoorhees (Is self MainActor?)
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem self is an actor (this is apple’s AVCam sample code)
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Many of Apple’s examples use concurrency incorrectly unfortunately.
I think this is just a bug producing a bad diagnostic? Does that seem like what you are seeing?
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem this is my problem, I can’t use swift 6 concurrency if, in the 4 hours I’ve used it, I’ve already run in to 2 compiler bugs (+ also the lack of annotations)
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Yeah it can be quite hard, especially right now.
If you do want to figure these things out we totally can. But staying in 5 mode is not just valid, but a good option for many (as long as you aren’t also currently using concurrency features)
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem I really want to use Swift 6 (at least in some small projects). Do you think it's at a point where putting in the time to figure everything out is worth it, or is it likely that in a few months / a year I would need to rewrite a bunch of code due to changes in how concurrency works (because that's what's happened over the past 1-2 years).
If it's a good time then I'll just bite the bullet, read through every article you've written, and try to adapt my code for Swift 6.
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees There are big changes looming. But I wouldn't be afraid to start now, especially for small projects. Fixing incorrect concurrency code (like that example) is 10x harder than starting with diagnostics on from the start.
But if you are starting from zero here, you don't have to read everything I've written! The step by step stuff I think provides a good foundation.
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem Cool, I'll give it a go.
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Don’t be shy with questions!
Dealing with missing SDK annotations is annoying but almost always easy.
90% of problems come from trying to use concurrency without isolation defined. Once you get why this is a problem and how to address it you’ll be fine.
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem you already receive too many questions, but I'm not sure how else to figure any of this out 😅
Here's a common issue I've run into. How do I "send" non-sendables? The sending keyword is great for function returns, but what about cases like this?
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Remember what I said about 90% of questions?
PhotoCapturer is a class with no isolation and an async method 😉
=> More informations about this toot | More toots from mattiem@mastodon.social
@finnvoorhees This might be what you actually want but it’ll require a lot more tricks. Are you certain you want non-isolated types here?
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem hmm, not really following. Sure I can make PhotoCapturer MainActor or an actor, but that doesn't fix the error in PhotoCaptureDelegate?
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Sorry! I assumed what motivated you to use this shared continuation was to avoid isolation mismatches with that delegate protocol you need conform to.
I haven't actually used a shared continuation in exactly this way before, but if you know that it's safe to move this type to an arbitrary thread here, we can cook something up. Will probably need to use a nonisolated(unsafe) opt-out.
=> More informations about this toot | More toots from mattiem@mastodon.social
@finnvoorhees There's also a bunch of (slightly dated, but possibly useful) stuff here that seems similar:
https://github.com/mattmassicotte/ConcurrencyRecipes/blob/main/Recipes/Protocols.md#non-isolated-nsobjectprotocol-inheriting-protocol
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem Ah that's what I was looking for, I can mark the photo as nonisolated(unsafe) when I know it's no longer accessed, and that silences the error.
Would be great if the compiler knew it was fine to send, but I'm assuming this is being worked on.
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees Great!
And, hope springs eternal.
=> More informations about this toot | More toots from mattiem@mastodon.social
@finnvoorhees Just to elaborate slightly, this pattern of a multi-step callback delegate is probably unsupportable. But I have not really put in the effort to prove that to myself.
So the "hope" here is that AVFoundation gets new APIs. I don't think the compiler can ever know this is current mechanism is safe unless lots of types become Sendable, which I imagine cannot happen.
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem It seems like the compiler should be able to figure out when non-sendables can be safely sent based on ref count + accesses (I'm sure there's a bunch of reasons why this is difficult).
In the simplest case, shouldn't the compiler know that this can't cause any data races?
=> More informations about this toot | More toots from finnvoorhees@mastodon.social
@finnvoorhees This is a great question actually.
I think the answer is that yes, it can (and does) know when it can see the internals of all functions.
But if those internals later changed, it would result in arbitrary non-local errors. You have to use sending to express this promise as part of your API. This is annoying for simple cases, but I think it is absolutely critical in the general case.
=> More informations about this toot | More toots from mattiem@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini