@aleck I think something that is missing here is the problem isn’t the delegate pattern at all. The issue is it’s hard to make classes Sendable. And the reason it’s hard is because it is almost never the right solution to isolation issues.
But the alternative, find out why you want this to be Sendable in the first place and change that might require rethinking how you are using concurrency.
@mattiem@aleck Matt, the alternative is unforcable if the requirement comes from the third-party dependency (sendable protocol). So what happened is I updated dependency, now it requires Sendable in that protocol and I should to adapt. I don't even use it for concurrency myself.
@ctietze@krzyzanowskim@aleck this is now a completely different problem. I don't think making a protocol Sendable is a good idea because it is extremely restrictive. But, actor and global-actor-isolated types are Sendable. So, if all the protocol's methods are async, then that's an option.
If not, this is an API that was easy to make, but will be extremely hard/impossible to use. And that is surprisingly easy to do with protocols + concurrency.
@krzyzanowskim yeah your example doesn’t make that clear at all. Just because FooDelegate protocol is Sendable, doesn’t mean that your Foo class needs to be Sendable. In your example you could just remove Sendable from Foo
Add comment