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 if and switch expressions #5472

Open
SimplyDanny opened this issue Feb 23, 2024 · 3 comments · May be fixed by #5832
Open

Rule Request: Prefer if and switch expressions #5472

SimplyDanny opened this issue Feb 23, 2024 · 3 comments · May be fixed by #5832
Labels
rule-request Requests for a new rules.

Comments

@SimplyDanny
Copy link
Collaborator

In version 5.9, Swift got support for if and switch expressions. A rule to enforce them where allowed should be possible.

In the first implementation, the rule does not need to be configurable. It should be opt-in and might support automatic rewriting.

Triggering:

func f(cond: Bool) -> Int {
    if cond {
        return 1
    } else {
        return 2
    }
}
func f(cond: Bool) {
    let r: Int
    if cond {
        r = 1
    } else {
        r = 2
    }
}

Non-triggering:

func f(cond: Bool) -> Int {
    if cond {
        // Nothing
    } else {
        return 2
    }
    return 1
}
@SimplyDanny SimplyDanny added the rule-request Requests for a new rules. label Feb 23, 2024
@AballahNsour
Copy link

AballahNsour commented May 17, 2024

will work on this request

@Brett-Best
Copy link

Brett-Best commented Jun 1, 2024

I'd really like to see this, I've provided another example below which covers:

  • Where you are assigning to self
  • When you call a method that returns Never e.g. fatalError
  • When you throw an error
import Foundation

enum SupportedFruit {
  case lemon
  case lime
  case orange
}

enum SupportFruitError: Error {
  case didYouMean(String)
}

// NON-TRIGGERING
extension SupportedFruit {
  init(rawValue: String) throws {
    self = switch rawValue {
    case "🍋": .lemon
    case "🍋‍🟩": .lime
    case "🍊": throw SupportFruitError.didYouMean("to use an orange emoji instead of tangerine emoji")
    default: fatalError()
    }
  }
}

// TRIGGERING
extension SupportedFruit {
  init(rawValue: String) throws {
    switch rawValue {
    case "🍋": self = .lemon
    case "🍋‍🟩": self = .lime
    case "🍊": throw SupportFruitError.didYouMean("to use an orange emoji instead of tangerine emoji")
    default: fatalError()
    }
  }
}

@AballahNsour I see you have a branch on your fork for starting the implementation of this rule, let me know if I can do anything to help out. My Swift Syntax skills are pretty lacking though 😢.

@leonardosrodrigues0 leonardosrodrigues0 linked a pull request Oct 21, 2024 that will close this issue
@leonardosrodrigues0
Copy link
Contributor

@Brett-Best Good point about branches that throw an error or return Never. AFAIK we can't check for the return value though. The solution could just check for branches throwing errors or maybe for explicit calls to fatalError.

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

Successfully merging a pull request may close this issue.

4 participants