Skip to content
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: Prefer for case let when nil tuple members are skipped #1977

Open
2 tasks done
jpsim opened this issue Dec 20, 2017 · 0 comments
Open
2 tasks done

Rule Request: Prefer for case let when nil tuple members are skipped #1977

jpsim opened this issue Dec 20, 2017 · 0 comments
Labels
rule-request Requests for a new rules.

Comments

@jpsim
Copy link
Collaborator

jpsim commented Dec 20, 2017

New Issue Checklist

Rule Request

We should prefer for case let when nil tuple members are skipped. For example, the general pattern

for (n1, n2, ...) in <sequence> {
  guard let nX = nX else {
    continue
  }
  // body
}
// or
for (n1, n2, ...) in <sequence> where nX != nil {
  // body
}

should be corrected to:

for case let (n1, n2, nX?) in <sequence> {
  // body
}
  1. Why should this rule be added? Share links to existing discussion about what
    the community thinks about this.

Rule should be added because it makes for more readable and concise code.

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

Here's a before/after commit from SwiftLint itself (a02d4e1)

-for (pattern, operatorString) in [toPattern, toNotPattern] {
-    guard let operatorString = operatorString else {
-        continue
-    }
-
+for case let (pattern, operatorString?) in [toPattern, toNotPattern] {

Would trigger:

for (n1, n2, ...) in <sequence> {
  guard let nX = nX else {
    continue
  }
  // body
}
// or
for (n1, n2, ...) in <sequence> where nX != nil {
  // body
}

Wouldn't trigger:

for case let (n1, n2, nX?) in <sequence> {
  // body
}
// or
for (n1, n2, ...) in <sequence> {
  // body, not skipping nX immediately or unconditionally
}
  1. Should the rule be configurable, if so what parameters should be configurable?

Should only be configurable on severity.

  1. Should the rule be opt-in or enabled by default? Why?

Enabled by default. I can't think of too many cases where you wouldn't want this.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
rule-request Requests for a new rules.
Projects
None yet
Development

No branches or pull requests

1 participant