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

Rule Request: Redundant ObjC attribute #2193

Closed
jpsim opened this Issue May 9, 2018 · 8 comments

Comments

Projects
None yet
4 participants
@jpsim
Copy link
Collaborator

jpsim commented May 9, 2018

New Issue Checklist

Rule Request

We should warn if you have @objc along with @IBInspectable/@IBDesignable/@IBOutlet/@IBAction, since they all imply @objc. Let's confirm this is the case unilaterally before doing this.

1. Why should this rule be added? Share links to existing discussion about what the community thinks about this.

No external discussions about this that I'm aware of.

2. Provide several examples of what would and wouldn't trigger violations.
// Trigger
@objc @IBInspectable private var rawStringValue: String? { ... }
@IBInspectable @objc private var rawStringValue: String? { ... }
@objc @IBAction private func didPress(_ sender: Any) { ... }
@IBAction @objc private func didPress(_ sender: Any) { ... }
// Wouldn't trigger
@objc private var rawStringValue: String? { ... }
@IBInspectable private var rawStringValue: String? { ... }
@objc private func didPress(_ sender: Any) { ... }
@IBAction private func didPress(_ sender: Any) { ... }
3. Should the rule be configurable, if so what parameters should be configurable?

I can't think of any useful configurations at the moment, other than the standard severity configuration.

4. Should the rule be opt-in or enabled by default? Why? See README.md for guidelines on when to mark a rule as opt-in.

Enabled by default if we can confirm that these attribute pairs are redundant in all cases. Opt-in otherwise.

@jpsim jpsim added the rule-request label May 9, 2018

@marcelofabri

This comment has been minimized.

Copy link
Collaborator

marcelofabri commented May 9, 2018

This probably should also catch uses of @objc inside a structure with @objcMembers.

@dirtydanee

This comment has been minimized.

Copy link
Contributor

dirtydanee commented May 13, 2018

If you guys don't mind, i would pick up and implement this rule.

I have ran a few tests, and it seems most of the @ prefixed attributes seems to be redundant with the @objc attribute.
The redundant candidates are:

@NSManaged
@IBAction
@IBOutlet
@IBInspectable
@GKInspectable

Non redundant candidate:

@NSCopying
@discardableResult
@available

Just to visualize what @marcelofabri meant with his last comment and my findings, the following would trigger / non-trigger:

// Trigger
@objc @IBInspectable private var foo: String? { ... }
@IBInspectable @objc private var foo: String? { ... }
@objc @IBAction private func foo(_ sender: Any) { ... }
@IBAction @objc private func foo(_ sender: Any) { ... }
@objc @GKInspectable private var foo: String! { ... }
@GKInspectable @objc private var foo: String! { ... }
@objc @NSManaged private var foo: String!
@NSManaged @objc private var foo: String!
@objcMembers
class Foo {
    @objc var bar: Any
}

// Not trigger
@objc private var foo: String? { ... }
@IBInspectable private var foo: String? { ... }
@objc private func foo(_ sender: Any) { ... }
@IBAction private func foo(_ sender: Any) { ... }
@GKInspectable private var foo: String! { ... }
private @GKInspectable var foo: String! { ... }
@NSManaged var foo: String!
@objc @NSCopying var foo: String!
@objc @discardableResult
func foo() -> UIView? {
      return nil
}
@objc @available(iOS 10.0, *, *)
func foo() -> UIView? {
     return nil
}
@objcMembers
class Foo {
    var bar: Any
}

Also, would it be okay, if it would be Swift 4.1+ rule?

@marcelofabri

This comment has been minimized.

Copy link
Collaborator

marcelofabri commented May 13, 2018

@dirtydanee As far as I know, nobody is working on this yet, so feel free to grab.

Preferably, we should support all Swift versions, but it's fine to support only 4.1+ if there're differences between SourceKit outputs that make the rule not possible on Swift < 4.1 or much harder to implement.

@jpsim

This comment has been minimized.

Copy link
Collaborator

jpsim commented May 13, 2018

Absolutely, I encourage you to pick this up!

Although I think there are a number of attributes that you didn’t include in your list. @available comes to mind.

@dirtydanee

This comment has been minimized.

Copy link
Contributor

dirtydanee commented May 15, 2018

I have updated my comment with @discardableResult and @available as non redundant examples.
There is also @nonobjc attribute, but if you use it together with @objc compiler error is being thrown. I could not find any other @ prefixed attribute.

If @objc attribute is used on an extension declaration, than the scope of the extension becomes visible for Objective C. I think this rule should also catch these use cases.

@SDGGiesbrecht

This comment has been minimized.

Copy link
Contributor

SDGGiesbrecht commented May 15, 2018

@dirtydanee,

I could not find any other @‐prefixed attribute.

Hier ist das gesammte Verzeichnis (mit Ausnahme den versteckten @_‐Attributen). Oft steht auch drin ob es @objc einbezieht:

NSManaged: [...] Applying this attribute also implies the objc attribute.


(🇬🇧🇺🇸EN: The whole list of attributes is here.)

@dirtydanee

This comment has been minimized.

Copy link
Contributor

dirtydanee commented May 21, 2018

Thanks for the list @SDGGiesbrecht !

After reading through the documentation, i came to the conclusion, that maybe only the ones having explicitly mentioned to be Applying this attribute also implies the objc attribute.

Based on the documentation it will be:

@NSManaged
@IBAction
@IBOutlet
@IBInspectable
@GKInspectable
@IBDesignable

I think the rest of the @ prefixed attributes can be ignored in this rule.

In my tests the only difference i found, if i apply the @objc modifier to a extension declaration, every method or computed property will be exposed to Objective C. However, if i add the @IBDesignable attribute to extensions, it will not expose the properties to Objective c, so there the @objc is not redundant.

@jpsim

This comment has been minimized.

Copy link
Collaborator

jpsim commented Nov 28, 2018

Done in #2270. Thanks @dirtydanee

@jpsim jpsim closed this Nov 28, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment