-
Notifications
You must be signed in to change notification settings - Fork 2.2k
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
Comments
will work on this request |
I'd really like to see this, I've provided another example below which covers:
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 😢. |
@Brett-Best Good point about branches that throw an error or return |
In version 5.9, Swift got support for
if
andswitch
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:
Non-triggering:
The text was updated successfully, but these errors were encountered: