4 ms·

Curious as to how this actually works under the hood. This looks like type erasure (checking the types in the compiler but treating everything as id under the

Curious as to how this actually works under the hood. This looks like type erasure (checking the types in the compiler but treating everything as id under the hood, similar to what Java does), whereas swift, if I'm not mistaken, uses reification for generics (creating separate copies of each class/function for each parameter type used in the application). Does that mean that the compiler is doing erasure for generics coming in from Objective C, inserting runtime casts where needed, but then doing full reification on swift code? Seems like that would have to be how it works, no?

mikeash 11y ago
There's not much reification to be done when dealing with ObjC objects and calling ObjC methods. For example: let a = A() a.someMethod() let b = B() b.someMethod() If A and B are Swift types, then the code to invoke a.someMethod() might be substantially different from the code for b.someMethod(). There's struct versus class, final methods, the potential for inlining, maybe more. If A and B are both Objective-C classes, however, then the code for the two invocations is identical. Both will compile down to a call to objc_msgSend, passing the object and the "someMethod" selector to it as parameters. So yes, it looks like the types get erased on the ObjC end of things, but I don't think the Swift end of things has to care very much. It can emit code without any runtime casts or any adjustment for the actual generic type.
netheril96 11y ago
> Does that mean that the compiler is doing erasure for generics coming in from Objective C, inserting runtime casts where needed The runtime types of Obj-C objects do not matter, as long as they can respond to the messages sent to them. In fact, you can cast any object to any class and gets no runtime errors, as long as the message you send is recognized. So reification is really not something useful in Obj-C.

mikeash 11y ago

There's not much reification to be done when dealing with ObjC objects and calling ObjC methods. For example: let a = A() a.someMethod() let b = B() b.someMethod() If A and B are Swift types, then the code to invoke a.someMethod() might be substantially different from the code for b.someMethod(). There's struct versus class, final methods, the potential for inlining, maybe more. If A and B are both Objective-C classes, however, then the code for the two invocations is identical. Both will compile down to a call to objc_msgSend, passing the object and the "someMethod" selector to it as parameters. So yes, it looks like the types get erased on the ObjC end of things, but I don't think the Swift end of things has to care very much. It can emit code without any runtime casts or any adjustment for the actual generic type.

netheril96 11y ago

> Does that mean that the compiler is doing erasure for generics coming in from Objective C, inserting runtime casts where needed The runtime types of Obj-C objects do not matter, as long as they can respond to the messages sent to them. In fact, you can cast any object to any class and gets no runtime errors, as long as the message you send is recognized. So reification is really not something useful in Obj-C.