This proposal, since it was first posted in June 2022, has become profoundly relevant, especially in the spring of 2024 when teams around the world are actively refactoring and revising Swift code in preparation for strict concurrency checking. I don't feel qualified to speak to the particulars of this proposal's merits, but I am more than qualified, having gone through enough refactors and revisions already, to point out specific real-world challenges that this proposal, or one like it, seems likely to solve.
For example, any application that uses CoreData's NSFetchedResultsController to configure and update a user interface almost certainly has a contact point, either directly or via an intermediary object, between an NSFetchedResultsController's delegate property and an object that has access to the user interface. NSFetchedResultsController is neither Sendable nor bound to any actor, whereas any object that interacts with user interface code (f.ex. a UIKit view controller) is almost certainly bound, wholly or in part, to the Main Actor. This mismatch in isolation has several inherent challenges, but among them is one that could be improved by this proposal. Good citizenship, when implementing the NSFetchedResultsControllerDelegate protocol, requires setting the delegate property of the controller to nil inside the deinit body of the delegate (for reasons inherent to CoreData implementation details that predate Swift and are outside the scope of my comment here):
@MainActor class SomeUIObject: NSObject, NSFetchedResultsControllerDelegate {
let controller: NSFetchedResultsController<MyModel>
deinit {
controller.delegate = nil
}
}
That deinit body will not compile without warnings under strict concurrency checks because NSFRC isn't Sendable. If I understand this proposal correctly, such a statement could be made, with minor adjustments, to happily compile and run on the Main Actor if this proposal were accepted.
I'm sure many other examples could be gathered besides this one, but I think this one is particularly relevant because of the ubiquity of CoreData and the long-standing need to nullify the delegate property during deinitialization (a best practice that is older than Swift itself).
What I hope to achieve with my comment here is not to provoke a discussion about the merits of CoreData in 2024, but rather, to shake the dust off of this proposal and renew interest in it, as I imagine it could be a godsend to teams like mine that have been resorting to a combination of locking mechanisms, generics, and @unchecked Sendable to skirt around compiler warnings in the interim.