Sendable Protocol Implementation for Services - Swift 6 Best Practices #53
Replies: 1 comment
-
Definitely not! If you don't think it's going to be send across isolation domains, there's no need to make this public struct Person: Sendable {
let name: String
}To mark these |
Beta Was this translation helpful? Give feedback.
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
-
I have a question about
Sendableimplementation for services that I'd like to clarify after completing the course.While I understand that all data models should be
Sendable(since we "send" them between threads), I'm unclear about whether and why services should also implement this protocol. The concept of "sending" services across concurrency domains doesn't feel as natural to me.For better context, let's consider public protocols that might be defined for example in some package - a situation where we can't rely on "implicit conformance to
Sendable" as it happens with internal actors. Also, please consider writing a new code in Swift 6, not a migration case.Example:
My understanding is that such a protocol would likely be used by a single type (e.g., a ViewModel), and I don't see how isolation changes would occur in this scenario. Or even if used in multiple parts of the app - each use case would just have its own, separate instance.
Questions:
UserProviderconform toSendable? What are the implications if it doesn't?Sendable(no matter if implicitly or explicitly)I'd appreciate any clarification on this topic, as it would help me better understand the practical application of
Sendablein real-world scenarios. If possible, I would love to see some examples why everything (if it's correct) should beSendableBeta Was this translation helpful? Give feedback.
All reactions