realm / realm/SwiftLint

Rule Request: check for method existence in #selector

Open
#2,084 3 comments 1 reaction 0 assignees View on GitHub

Nobody has claimed this yet.

rule-request
Dominant language
Swift
Stars
19.7k
Forks
2.3k
Avg merge
1d 1h
Merged PRs (30d)
11

Description

New Issue Checklist
Rule Request

If this is a new rule request, please ignore all sections below this one, format
this issue's title as Rule Request: [Rule Name] and describe:

Describe:
#selector() doesn't warn you if you reference method from different class. In class A you could be adding target to button button.addTarget(self, action: #selector(B.didTap), for: .touchUpInside) and as long as B.didTap is accessible this code compiles but on tap of the button crashes the app. I would keep this rule simple and it would only check for existence of method in case target is being added to self.

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

I don't have link to an existing discussion.

  1. Provide several examples of what would and wouldn't trigger violations.

What would trigger:

final class A: UIViewController {
  override func viewDidLoad() {
    super.viewDidLoad()
    let button = UIButton()
    button.addTarget(self,
                                   action: #selector(B.didTap),
                                   for: .touchUpInside)
  }
}

what wouldn't trigger:

final class A: UIViewController {
  override func viewDidLoad() {
    super.viewDidLoad()
    let button = UIButton()
    button.addTarget(self,
                                   action: #selector(A.didTap),
                                   for: .touchUpInside)
  }
}
  1. Should the rule be configurable, if so what parameters should be configurable?

This rule should not be configurable.

  1. 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.

I believe this rule should be enabled by default.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing README.md for the opt-in rule guidance, then locate SwiftLint's rule implementation and tests for Swift selector analysis. Use the supplied addTarget examples to define the expected behavior: report a selector naming a method from another class when the target is self, while accepting the matching class.

Written by the indexing model from the issue text.

Assessment

Tech stack
swift
Domain
devtools
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.