-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Added @MainActor to SharedSequence function arguments #2613
base: main
Are you sure you want to change the base?
Conversation
…g closure arguments.
I think instead of adding Not sure if that's possible, but it seems to be more reasonable and more elegant. Feel free to correct me if I am wrong, or share your thoughts! |
The problem is, that there's no way to transport the fact that anything running on the MainScheduler is being performed on the MainActor. Each function has its own signature. I can see no way to apply I've been experimenting with adding an actor type to the type signature to solve this, so the actor isolation could be passed up and down the chaing and changed by using I failed at getting this implemented, because even if you do add an actor there, it does not add said actor to the function signatures. The only way to add that type to the function signatures would be to use add the actor type's instance to its signature like this (pseudo): SharedSequence<SharingStrategy, Element, ActorType: Actor> {
func map<NewElement>(_ transform: (isolated ActorType, Element) -> NewElement) -> SharedSequence<SharingStrategy, Element, ActorType> {
…
}
} The problem here is: even if |
Thanks for the detailed reply @fabianmuecke!
I totally understand that, since I have been facing similar issues in my working projects. That's why I am asking is it possible to perform the same way in RxSwift. In this case, I personally think using attributes this is a possble way to handle it properly. side note: |
Yeah, if we want to make RxSwift be at least publicly compliant, this needs more work. Especially all Fortunately the strict concurrency compilation will simply tell you to add |
To get started on #2586 this PR adds
@preconcurrency @MainActor
to functions ofSharedSequence
,Driver
, andSignal
, which take function arguments and adds@MainActor
to the according function argument signatures.I added this for all according
SharedSequence
functions, although technically it would be possible, to create a customSharedSequence
type, which does not use theMainScheduler
. I tried to find a way to limit this toSharingStrategy
s, which use theMainScheduler
, but failed to check that properly at compile-time, because the scheduler can be exchanged for a mock.This means that:
Important
Before this gets merged, the
SharedSequence
functions should probably be separated bySharingStrategy
type and@MainActor
addition limited toSignalSharingSharingStrategy
, andDriverSharingStrategy
, so it doesn't break possibly existing custom implementations ofSharingStrategyProtocol
out there.Alternatively we could introduce a
MainSchedulerSharingStrategy
marker protocol, which would allow to limit it to sharing strategies conforming to that protocol and allow for easier adoption in custom implementations of sharing strategies (which might also be usingMainScheduler
).I didn't go the extra mile of doing anything like that, because I first wanted to hear, if you consider adding
@preconcurrency
to introduce@MainActor
to the code base is the right direction to go.So please let me know what you think.