-
Notifications
You must be signed in to change notification settings - Fork 31
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conform all models to Sendable
protocol?
#26
Comments
Great idea! |
Ok, just had time to think about this. The resources themselves can't be So: do you need the resource types to be |
Sorry for the long reply, had a lot going on on my plate 😅 Nope, here's the full pseudocode of the actor: actor PatientR4StorageImpl: PatientR4Storage {
func getPatients() throws -> [ModelsR4.Patient] {
let url = URL(string: "url/to/file")!
let data = try Data(contentsOf: url)
let bundle = try JSONDecoder().decode(ModelsR4.Bundle.self, from: data)
let patients = bundle.entry?.compactMap { entry in
entry.resource?.get(if: ModelsR4.Patient.self)
}
return patients!
}
} So answering your question: the method is isolated, and I still get this warning. As I mentioned earlier, the reason for this is because I've enabled Currently, I don't see any problems with the fact that the models don't conform to the Maybe you could use |
This method doesn't need to be actor-isolated because it's not using any actor state, you can just make it a Instances of these classes are truly not sendable because they are classes with simple properties that any thread can change. I don't think it's desirable to wrap access to all the properties in some form of mutex. I also don't think they need be sendable, mutability is often desired and ensuring thread-safe access where necessary should be rare? |
Correct, it doesn't use any mutable state just yet — this will change in the future. It's just sample code so you can get the surrounding context about where the warning happens.
Well, should be. I can imagine a situation where the developer may forget that the |
Classes with mutable properties inherently are not thread safe. I don't think it makes sense to try to change this in FHIRModels. |
Currently, I'm working on my pet project, and I've turned on
SWIFT_STRICT_CONCURRENCY = complete
for my project. And here's what the compiler gives me:I think it would be good to conform the models to the
Sendable
protocol in the context of the wide adoption of the actor-based concurrency modelThe text was updated successfully, but these errors were encountered: