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-9919] Classes marked as @objcMembers don't warn if not inherited from NSObject #52325
Comments
I think this is correct behavior. A non-NSObject-inheriting class can have |
Ha! |
You'd have to pass an instance of the class to Objective-C yourself, but you can certainly do that if you want. (Also, strictly speaking these classes can still be found through NSClassFromString.) The original motivation for accepting this was to allow pure Swift classes to conform to Objective-C protocols. Given how many Objective-C protocols depend on NSObject-ness in practice, though, I'm not sure how useful it's actually turned out to be. |
Swift classes not inheriting NSObject are still valid Objective-C classes, and can have `@objc` methods... they just won't be visible to Objective-C source code because they don't show up in the generated header. In that sense, it's not wrong to allow `@objcMembers` on a Swift class not inheriting from NSObject. My inclination is to say this is not a bug, and say that we don't want a warning for this case: it's not wrong to have `@objcMembers` without inheriting NSObject, and if we add a warning it would suggest that `@objc` and `@objcMembers` are strongly tied together—but they really aren't in the model. Adding a warning also requires adding a way to suppress that warning (e.g., by adding`@nonobjc`). |
@AliSoftware, do you still feel that a warning would be beneficial here? |
@DougGregor But to be honest, even if But you're also right that if we add a warning (which would be equally triggered by Maybe a better/ideal solution to the problem would be to add a way (accessible from the IDE like under the 4-squares Ctrl-1 menu (View > Standard Editor > Show Related Item) or something?) to help diagnose why a class isn't exposed to ObjC source code (why it won't appear in the generated header)?
I realize that might this idea will probably be more work than just adding a warning though, and I might be asking for that just because I lost a lot of time recently because of that, which a diagnostic could have prevented, so was quite frustrating… but it's not the first time I saw situations like that so some help from the compiler to diagnose that (on demand or via a warning) would definitively have helped those times ;-) |
We're not going to have warnings in all those cases. |
Yeah, that's why I said that a better ideal solution would be something different and separate from just something specifically tied to Maybe you'd prefer we close that bug report related to |
Additional Detail from JIRA
md5: 924803a6681795b962e04f6332511076
Issue Description:
Summary
A pure Swift class non-inheriting NSObject can be marked as
@objcMembers
Expected results
The compiler should error when classes not inheriting NSObjects are declared as
@objcMembers
, the same way it errors about those with@objc
Actual results
No error (and the class is omitted from the generated interface)
Example
When annotating with
@objc
we get the following expected error:But when annotating with
@objcMembers
we don't and this compiles without any error:The text was updated successfully, but these errors were encountered: