Open levibostian opened 4 months ago
It is really common to try to use locked wrappers for these kinds of problems.
https://mastodon.social/@cocoaphony/112134000958953244
I think it may be worthwhile to include something like this. However, in my own code I have migrated towards other approaches. Here's what I wrote in response to that post:
I think it is correct.
On my journey, I did stuff like this. And over time, I began to focus more on minimizing the need to cross boundaries, instead of making it easier. It can be a lot easier said than done though.
So while I am very into suggesting this as an option, I think the default for many is "I just want this to be Sendable" and I think that can be a trap. Now, like I said, just because I think it is a bad idea, doesn't make it any easier to do something else. Expanding actor boundaries can require redesigning your system, and that is often just infeasible.
I am quite new to Swift concurrency so I greatly appreciate the wisdom of others in this project to help me determine if this is a valid recipe or not. Any feedback is welcome!
A Xcode compiler warning that I receive a lot is:
Example of code that would give me this warning:
Because I saw this warning so much in my project, I wanted to see if there was a way that I could resolve all these warnings using a common design pattern while not having to use
@unchecked Sendable
for my data structure.This is the "recipe" that I came up with.
First, create this class that acts as a wrapper around a generic data type:
Then, taking the code I gave earlier in this issue, I can apply this refactor:
The warnings are gone, yes, but at a cost. You have to change the way you get/set the property in your class:
I would love to use something like a property wrapper to bring back the get/set syntax but the original xcode warning would still exist:
I think recipes to resolve this compiler warning is missing from this project. Any interest in contributions for recipes for this warning?