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

for_where doesn't catch nested ifs with pattern-matching #2053

Closed
2 tasks done
tomquist opened this issue Feb 15, 2018 · 3 comments
Closed
2 tasks done

for_where doesn't catch nested ifs with pattern-matching #2053

tomquist opened this issue Feb 15, 2018 · 3 comments
Labels

Comments

@tomquist
Copy link
Contributor

New Issue Checklist

Bug Report

I think the change done in #1978 is based on wrong assumptions and should be undone. The example outlined in #1968 can be expressed as follows:

enum Value {
    case valueA, valueB(a: Int)
}

func firstIndexOfValueB(in array: [Value]) -> Int? {
    for case let (index, .valueB) in array.enumerated() {
        return index
    }
    return nil
}

Maybe the name of the rule is misleading because there is no where keyword in the for-loop. There are two possible solutions:

  1. Undo the change in Fix false positives in for_where with pattern matching #1978 and change the description of the rule to "where clauses or pattern-matching are preferred over a single if inside a for.". The name should probably also be changed but the identifier has to stay the same for compatibility reasons.
  2. Don't undo the change and create another rule to catch only the pattern-matching case
@marcelofabri
Copy link
Collaborator

@tomquist Can you take a look on #1977? I think this is a duplicate of that rule request.

@tomquist
Copy link
Contributor Author

@marcelofabri I agree that these have similarities but #1977 explicitly talks about unwrapping of optionals with a guard statement which should be autocorrected but I'm talking about pattern matching in general. Maybe it also makes sense to merge #2053 and #1977.

@stale
Copy link

stale bot commented Nov 8, 2020

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!

@stale stale bot added the wontfix label Nov 8, 2020
@stale stale bot closed this as completed Nov 15, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants