To summarise, remove @NSManaged from the core language and reimplement it as a property wrapper. @NSManaged is a vestige from the early days of Swift which is no longer needed.
I have an example implementation of how this can be done with my GitHub - jjrscott/Mogen: Type-safe CoreData in Swift but this really just shows how easy it would be implement in CoreData itself (even more so as Apple can get access to the property names without the need to use a parameter).
Without @NSManaged it’s impossible to implement a property that interops with Core Animation’s action system. It’s still an important part of the language for objc interop to be able to define a property without providing an implementation.
Personally, I agree this should probably be renamed, if only because it’s useful for more than just Core Data.
I’d always assumed @NSManaged was a synonym for dynamic but now I’m not so sure.
To be clear, I’m proposing the removal of @NSManaged, dynamic would remain unchanged.
Yeah, it's not a synonym.
@NSManaged says to not create an implementation of the property, and to use an Objective-C calling convention.
dynamic is merely always dispatched with an Objective-C convention.
In the NSManaged case, when the message is sent, the runtime realizes that the implementation is missing and then tries various messages such as forwarding target for selector and -forwardInvocation: to find it. Both Core Animation and Core Data hook into this system to provide the appropriate implementation for their use case.
You may be confusing Swift dynamic and Objective-C @dynamic. The former is to force message dispatching when calling a method from Swift, and the later to let the compiler know that the property will be synthezised at runtime and it should not try to synthesised property itself.
Thanks @benpious and @Jean-Daniel for correcting my error.
I do still assert that the features provided by @NSManaged relating to CoreData would now be better implemented through property wrappers rather than being core to the language (as shown in Mogen). The same applies to CoreAnimation, in fact CABasicAnimation would very much benefit from typing and key paths.
I can see why Apple may with to keep it as a internal for their own libraries, but it shouldn't be exposed to the outside world.
@NSManaged cannot be implemented as a property wrapper. As already stated, @NSManaged implies @objc and dynamic and prevents storage or accessors from being generated, something that's not normally allowed. I agree that it would be nice™ to not have it as a core attribute, and that code synthesis can probably replace its current uses, but that does not mean it can be removed.
My apologies, I was insufficiently precise. What I meant to say was that I think that the features based on @NSManaged usage would now be far better implemented through property wrappers. The current function enabled by @NSManaged is subpar in the current Swift (CAPropertyAnimation.keyPath is an NSString and NSManagedObject relations being forced to be an NSSet are obvious examples)
I appreciate it's likely out of the question for Swift 5, but should, in my view, be on the table for Swift 6.