Rule Request: Redundant ObjC attribute

[jpsim]

New Issue Checklist

• Updated SwiftLint to the latest version
• I searched for existing GitHub issues

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.

[marcelofabri]

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

[dirtydanee]

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]

@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]

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]

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]

@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]

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]

Done in #2270. Thanks @dirtydanee