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

Update no_fallthrough_only rule condition to handle @unknown default #2696

Closed
zntfdr opened this issue Mar 28, 2019 · 3 comments · Fixed by #2770
Closed

Update no_fallthrough_only rule condition to handle @unknown default #2696

zntfdr opened this issue Mar 28, 2019 · 3 comments · Fixed by #2770
Labels
enhancement Ideas for improvements of existing features and rules.

Comments

@zntfdr
Copy link
Contributor

zntfdr commented Mar 28, 2019

In swift 4.2 and later we can use @unknown default in a switch block case to handle future enum cases.
This is ok however, as far as I know, this case has to be handled separately from other cases in a switch.

Let's say that we have the following script:

#!/usr/bin/swift
import Foundation

enum EnumExample {
    case caseA, caseB
}

let enumInstance: EnumExample = .a

switch enumInstance {
case .caseA:
    print("it's a")
case .caseB:
    fallthrough
@unknown default:
    print("it's not a")
}

This works as expected, however, again, as far as I know, there's no way to merge the cases case .caseB: and @unknown default:.

As the latest SwiftLint version (0.31.0), this code triggers the no_fallthrough_only warning:

warning: No Fallthrough Only Violation: Fallthroughs can only be used if the `case` contains at least one other statement. (no_fallthrough_only)

Steps to Reproduce

  1. copy the code above in a empty .swift file
  2. make said file executable (if you want to run it) by running $ chmod +x YOURFILENAME.swift
  3. run $ swiftlint

Expected Results

no no_fallthrough_only warning

Actual Results

no_fallthrough_only warning

I understand why the warning triggers, however I believe this case where we use @unknown default should be an exception to this rule.

Thank you in advance for all the support! 🤗

@rzulkoski
Copy link

Running into this same scenario, would greatly appreciate the proposed exception!

@marcelofabri marcelofabri added the enhancement Ideas for improvements of existing features and rules. label Apr 1, 2019
@jpsim
Copy link
Collaborator

jpsim commented Apr 7, 2019

Perhaps we could/should silence violations that fall through to an @unknown default case?

@zntfdr
Copy link
Contributor Author

zntfdr commented Apr 8, 2019

Perhaps we could/should silence violations that fall through to an @unknown default case?

@jpsim I’d be ok with that 😊

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Ideas for improvements of existing features and rules.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants