[#]SwiftUI onPreferenceChange now requires a Sendable non-async closure in Xcode 16.2.
Does this mean we aren't supposed to be manipulating view state when a Preference value changes? Kicking off a Task satisfies the compiler, but seems like a bad idea.
How exactly are we supposed to be using onPreferenceChange now? Are there any other ways of passing values up the hierarchy that still work? Why aren't breaking changes like this explained in the release notes?
=> More informations about this toot | More toots from dale_price@mastodon.online
@dale_price This has come up quite a lot, unfortunately m. Why does a Task seem bad? I think it is exactly the right solution.
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem Tasks could get queued up and run in any order, right? Seems like it could cause reentrancy issues, especially if there are multiple changes to the preference value in rapid succession. I.e. by the time it runs, it might be setting an outdated value
=> More informations about this toot | More toots from dale_price@mastodon.online
@dale_price Tasks are (as of Swift 6 compiler) enqueued synchronously! They will begin in the order they are created.
=> More informations about this toot | More toots from mattiem@mastodon.social
@mattiem ah, I didn't realize that! Should be fine then.
Do you know if that’s dependent on Swift 6 language mode, or is it also true with the 5.x language mode on the 6 compiler? (I'm using Swift 6 mode on this project, but still curious)
=> More informations about this toot | More toots from dale_price@mastodon.online
@dale_price This behavior requires a 6 compiler only, not 6 mode. (It relies on the @.isolated(any) feature)
=> More informations about this toot | More toots from mattiem@mastodon.social This content has been proxied by September (3851b).Proxy Information
text/gemini