if let
and guard let
serve similar, but distinct purposes.
The "else" case of guard
must exit the current scope. Generally that means it must call return
or abort the program. guard
is used to provide early return without requiring nesting of the rest of the function.
if let
nests its scope, and does not require anything special of it. It can return
or not.
In general, if the if-let
block was going to be the rest of the function, or its else
clause would have a return
or abort in it, then you should be using guard
instead. This often means (at least in my experience), when in doubt, guard
is usually the better answer. But there are plenty of situations where if let
still is appropriate.
When you use guard you have a much higher expectancy for the guard to succeed and it's somewhat important that if it doesn't succeed, then you just want to exit scope early. Like you guard to see if a file/image exists, if an array isEmpty or not.
func icon() -> UIImage {
guard let image = UIImage(named: "Photo") else {
return UIImage(named: "Default")! //This is your fallback
}
return image //-----------------you're always expecting/hoping this to happen
}
If you write the above code with if-let it conveys to the reading developer that it's more of a 50-50. But if you use guard you add clarity to your code and it implies I expect this to work 95% of the time...if it ever failed, I don't know why it would; it's very unlikely...but then just use this default image instead or perhaps just assert with a meaningful message describing what went wrong!
Avoid
guard
s when they create side effects, guards are to be used as a natural flow. Avoid guards whenelse
clauses introduce side effects. Guards establish required conditions for code to execute properly, offering early exitWhen you perform significant computation in the positive branch, refactor from
if
to aguard
statement and returns the fallback value in theelse
clauseFrom: Erica Sadun's Swift Style book
Also as a result of the above suggestions and clean code, it's more likely you will want/need to add assertions into failed guard statements, it just improves readability and makes it clear to other developers what you were expecting.
guard let image = UIImage(named: selectedImageName) else { // YESSSSSS assertionFailure("Missing \(selectedImageName) asset") return } guard let image = UIImage(named: selectedImageName) else { // NOOOOOOO return }
From: Erica Sadun's Swift Style book + some modifications
(you won't use asserts/preconditions for if-let
s. It just doesn't seem right)
Using guards also help you improve clarity by avoiding pyramid of doom. See Nitin's answer.
There is one important difference that I believe no one has explained well.
Both guard let
and if let
unwrap the variable however
With guard let
you are creating a new variable that will exist outside the else
statement.
With if let
you aren't creating any new variable—after the else statement, you only enter the code block if the optional is non-nil. The newly created variable exists only inside the code block not after!
guard let:
func someFunc(blog: String?) {
guard let blogName = blog else {
print("some ErrorMessage")
print(blogName) // will create an error Because blogName isn't defined yet
return
}
print(blogName) // You can access it here ie AFTER the guard statement!!
//And if I decided to do 'another' guard let with the same name ie 'blogName' then I would create an error!
guard let blogName = blog else { // errorLine: Definition Conflicts with previous value.
print(" Some errorMessage")
return
}
print(blogName)
}
if-let:
func someFunc(blog: String?) {
if let blogName1 = blog {
print(blogName1) // You can only access it inside the code block. Outside code block it doesn't exist!
}
if let blogName1 = blog { // No Error at this line! Because blogName only exists inside the code block ie {}
print(blogName1)
}
}
For more info on if let
do see: Why redeclaration of optional binding doesn't create an error
(Also mentioned in Rob Napier's answer) :
You MUST have guard
defined inside a func. It's major purpose is to abort/return/exit scope, if a condition isn't met:
var str : String?
guard let blogName1 = str else {
print("some error")
return // Error: Return invalid outside of a func
}
print (blogName1)
For if let
you don't need to have it inside any func:
var str : String?
if let blogName1 = str {
print(blogName1) // You don't get any errors!
}
guard
vs if
It's worth noting that it's more appropriate to see this question as guard let
vs if let
and guard
vs if
.
A standalone if
doesn't do any unwrapping, neither does a standalone guard
. See example below. It doesn't exit early if a value is nil
. There are NO optional values. It just exits early if a condition isn't met.
let array = ["a", "b", "c"]
func subscript(at index: Int) -> String?{
guard index > 0, index < array.count else { return nil} // exit early with bad index
return array[index]
}
When to use if-let
and when to use guard
is often a question of style.
Say you have func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int
and an optional array of items (var optionalArray: [SomeType]?
), and you need to return either 0
if the array is nil
(not-set) or the count
if the array has a value (is set).
You could implement it like this using if-let
:
func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int
{
if let array = optionalArray {
return array.count
}
return 0
}
or like this using guard
:
func collectionView(collectionView: UICollectionView, numberOfItemsInSection section: Int) -> Int
{
guard let array = optionalArray else {
return 0
}
return array.count
}
The examples are functionally identical.
Where guard
really shines is when you have a task like validating data, and you want the function to fail early if anything is wrong.
Instead of nesting a bunch of if-let
s as you get closer to finishing validation, the "success path" and the now successfully bound optionals are all in the main scope of the method, because the failure paths have all returned already.
I'll try to explain the usefulness of guard statements with some (unoptimized) code.
You have a UI where you are validating text fields for user registration with first name, last name, email, phone and password.
If any textField is not containing valid text, it should make that field firstResponder.
here is the unoptimized code:
//pyramid of doom
func validateFieldsAndContinueRegistration() {
if let firstNameString = firstName.text where firstNameString.characters.count > 0{
if let lastNameString = lastName.text where lastNameString.characters.count > 0{
if let emailString = email.text where emailString.characters.count > 3 && emailString.containsString("@") && emailString.containsString(".") {
if let passwordString = password.text where passwordString.characters.count > 7{
// all text fields have valid text
let accountModel = AccountModel()
accountModel.firstName = firstNameString
accountModel.lastName = lastNameString
accountModel.email = emailString
accountModel.password = passwordString
APIHandler.sharedInstance.registerUser(accountModel)
} else {
password.becomeFirstResponder()
}
} else {
email.becomeFirstResponder()
}
} else {
lastName.becomeFirstResponder()
}
} else {
firstName.becomeFirstResponder()
}
}
You can see above, that all the strings (firstNameString, lastNameString etc) are accessible only within the scope of the if statement. so it creates this "pyramid of doom" and has many issues with it, including readability and ease of moving things around (if the fields' order is altered, you have to rewrite most of this code)
With the guard statement (in the code below), you can see that these strings are available outside the {}
and are made use of, if all fields are valid.
// guard let no pyramid of doom
func validateFieldsAndContinueRegistration() {
guard let firstNameString = firstName.text where firstNameString.characters.count > 0 else {
firstName.becomeFirstResponder()
return
}
guard let lastNameString = lastName.text where lastNameString.characters.count > 0 else {
lastName.becomeFirstResponder()
return
}
guard let emailString = email.text where
emailString.characters.count > 3 &&
emailString.containsString("@") &&
emailString.containsString(".") else {
email.becomeFirstResponder()
return
}
guard let passwordString = password.text where passwordString.characters.count > 7 else {
password.becomeFirstResponder()
return
}
// all text fields have valid text
let accountModel = AccountModel()
accountModel.firstName = firstNameString
accountModel.lastName = lastNameString
accountModel.email = emailString
accountModel.password = passwordString
APIHandler.sharedInstance.registerUser(accountModel)
}
If the order of the fields changes, just move respective lines of code up or down, and you are good to go.
This is a very simple explanation and a use case. Hope this helps!
Basic Difference
return
, throw
etc.return
statement. But we can writeNOTE: Both are used to unwrap the Optional variable.
guard
A
guard
statement is used to transfer program control out of a scope if one or more conditions aren’t met.The value of any condition in a
guard
statement must be of typeBool
or a type bridged toBool
. The condition can also be an optional binding declaration.
A guard statement has the following form:
guard condition else {
//Generally return
}
if let
- Also popular as optional binding.
- For accessing optional object we use
if let
.
if let roomCount = optionalValue {
print("roomCount available")
} else {
print("roomCount is nil")
}
The clearest explanation I saw was in the Github Swift Style Guide:
if
adds a level of depth:
if n.isNumber {
// Use n here
} else {
return
}
guard
doesn't:
guard n.isNumber else {
return
}
// Use n here
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With