New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SR-2267] Nested Swift classes fail to link for Objective-C #44874
Comments
It's not looking like we'll get to this for 3.0. Would you be able to un-nest the class and put a nested typealias in its place as a workaround? |
Joe, is this hard to fix? |
I'll investigate. The nested class thing was a work-around Swift's lack of namespaces coupled with ObjC's inability to understand anything that isn't an NSObject. I'm trying to avoid AlamoFire situation where you import AF-specific things with names like Manager, Request, Error, and Result into the top-level namespace. I'll explore other approaches to avoiding this. |
@slavapestov Probably not, since it apparently worked in 2.x. |
This is failing because the nested class has a dynamically-initialized parent field:
|
@rjmccall, do you have any ideas on how to solve this? Should we initialize the parent field lazily, and load it with a runtime function call? |
Eh. I don't think initializing the parent field lazily is a good idea; for generic parents, I think having fast access to the parent will be fairly important. There are classes that require dynamic initialization before the ObjC runtime gets to them, e.g. if they have a generic superclass or a resilient field. I think it's reasonable to say that having a parent type ought to put you in that category. If we have a mechanism to make those classes linkable from ObjC, great, but otherwise we'll need to prevent the @objc attribute. |
Mind explaining to a bystander why the parent field can't be hardcoded here? The parent class isn't generic, so shouldn't we be able to just use it directly? |
The ObjC runtime reserves the right to relocate classes at realization time. |
Ah, right, thanks. |
Comment by Noam Tamim (JIRA) Is there a plan to fix it? Is it recognized as a bug? |
Fundamentally, Swift classes can't be reliably exported to ObjC at compile time if we need to reify their metadata at runtime, for the reasons John outlined above, so the "fix" would have to be to disallow the @objc attribute on nested classes. You'll have to un-nest your class to be able to link to it from ObjC, or else export a Swift method to ObjC that returns the |
@jckarter we need to solve this for resilience though, so that ObjC classes can contain fields of resilient value type. |
Attachment: Download
Environment
Version 8.0 beta (8S128d)
OS X 10.11.5 (15F34)
Additional Detail from JIRA
md5: 9db79b3a5d2d7184d24530456c5091fb
is duplicated by:
Issue Description:
The following Swift 2.2 code compiles under Swift 3, but will not link if Objective-C code attempts to reference it from another module:
This compiles, but fails to link, generating the error:
Note that this symbol is missing, but the metaclass is available:
When built using Xcode 7.3, both are included:
Steps to Reproduce:
Create Swift module that exposes nested class to ObjC.
Create test case in ObjC that references that symbol
Link
The text was updated successfully, but these errors were encountered: