unused_setter_value incorrectly triggers for overridden properties.

[Coeur]

New Issue Checklist

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

Describe the bug

unused_setter_value incorrectly triggers for overridden properties.

I use the following code that I gave as a Stack Overflow answer:

/// sub-class to disallow selection.
class UnselectableTappableTextView: UITextView {
    // required to prevent blue background selection from any situation
    override var selectedTextRange: UITextRange? {
        get { return nil }
        // This triggers a SwiftLint violation:
        set {}
    }
}

Having an empty setter is the desired behavior when overriding.

Environment

• SwiftLint version 0.30.0
• Xcode 10.1
• Swift 4.2

[jpsim]

Yeah I agree we should allow no-op sets for overridden variables.

[jgavris]

+1, Similarly for @available(*, unavailable) properties.

[marcelofabri]

Note: you can silence the warning:

override var selectedTextRange: UITextRange? {
        get { return nil }
        set { _ = newValue }
    }

[jpsim]

That's a good workaround for now @marcelofabri although I think we should also implement this change because users shouldn't adapt their code just to satisfy SwiftLint unless it's also better for other reasons. I think in this case, an empty set sufficiently conveys the author's intention to not do anything with newValue.

[marcelofabri]

yeah, but this will be a warning on Swift too soon: swiftlang/swift#21983 and https://bugs.swift.org/browse/SR-964

I don't mind changing the behavior though, so PRs are welcome!

[stale]

This issue has been automatically marked as stale because it has not had any recent activity. Please comment to prevent this issue from being closed. Thank you for your contributions!

[username0x0a]

This change appears nice, but it would be good to have an option (attribute?) to allow enforcing this rule on overrides as well as that might be the actual rule decision our team took for example – we're used to use the _ = newValue workaround when it's really desired, yet it can be still useful on overrides wrapping something else on inherited instances.

[Coeur]

For readers, to clarify, even though it's labeled as "wontfix", it got fixed on 21 Jan 2022 with #3653, three years after the issue was opened. 🎉
It got released in SwiftLint 0.46.1 the next day.