Sorry, I was being generic (!) because there are a number of cases where methods return a subclass. Typically they are category and protocol class methods where the behavior is exactly the same but the returned class type varies.
Here’s a concrete example:
- (NSArray<__kindof NSManagedObject*>) getAllOfMeInContext:(NSManagedObjectContext context);
Callers could then use it without having to cast to a specific subclass:
NSArray<Foo*>* allFoos = [Foo getAllOfMeInContext:context];
In Swift I could get the same behavior:
class func getAllOfMe(in context: NSManagedObjectContext) -> [T] where T: NSManagedObject
let allFoos = Foo.getAllOfMe(in: context) // == [Foo]
If I try to get the “kindof” behavior in the Swift version replacing the Obj-C method, the compiler complains once about generics (cannot use generics with @objc). If I just return, i.e.,
[NSManagedObject], then I get a ton of incompatible pointer type warnings.
The migration process will proceed at a snail’s pace relative to other work, so there will be a mix of Swift and Obj-C for some time. I’m trying to avoid two things:
The need to go through and cast result types that didn’t need to be cast before; and
Keeping separate Obj-C and Swift versions of these methods to satisfy #1.
I could migrate as much as possible to Swift and bite the bullet on #2 for now, but I’m trying to avoid the case where something gets fixed in one method and not the other.