Oh I see. I think the problem is that with Objective-C generics, you can always cast from Foo<A> to Foo<B>, because the type parameters do not really exist. Swift’s type checking logic for casts assumes Swift generic semantics, where in general Foo<A> and Foo<B> are unrelated types.
Do you mind filing a bug? Slava > On Oct 6, 2017, at 11:40 PM, Glen Huang <hey...@gmail.com> wrote: > > NSFetchedResultsController is the class from Core Data: > > https://developer.apple.com/documentation/coredata/nsfetchedresultscontroller > >> On 7 Oct 2017, at 2:38 PM, Slava Pestov <spes...@apple.com> wrote: >> >> Can you post a self-contained example, including the declaration of >> NSFetchedResultsController? >> >> Slava >> >>> On Oct 6, 2017, at 11:28 PM, Glen Huang via swift-users >>> <swift-users@swift.org> wrote: >>> >>> Hi, >>> >>> I defined some concrete classes inheriting from a generic class like this: >>> >>> class Controller1: NSFetchedResultsController<NSManagedObject> {} >>> class Controller2: NSFetchedResultsController<NSManagedObject> {} >>> >>> And I assign them a shared delegate, and in the delegate method: >>> >>> func controllerWillChangeContent(_ controller: >>> NSFetchedResultsController<NSFetchRequestResult>) >>> >>> I want to test the concrete type of controller, doing things differently >>> for Controller1 and Controller2. >>> >>> But doing the following gives me a warning: Cast from >>> 'NSFetchedResultsController<NSFetchRequestResult>' to unrelated type >>> 'Controller1’ always fails >>> >>> switch controller { >>> case is Controller1: >>> // ... >>> default: >>> break >>> } >>> >>> I wonder what’s the correct way to check the concrete type? >>> >>> Regards, >>> Glen >>> _______________________________________________ >>> swift-users mailing list >>> swift-users@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-users >> > _______________________________________________ swift-users mailing list swift-users@swift.org https://lists.swift.org/mailman/listinfo/swift-users
