In the calendar code I would not use Calendar.current. I recently had to fix a crash related to this. Create a Calendar manually with the Gregorian identifier or you may get unknown behavior. The issue is that the user may have a non-Gregorian calendar set
'm new to Swift and trying to solve some LeetCode problems in Xcode. I realized that I can't debug in Playgrounds, which makes it hard to see what I'm doing. How can I learn Swift effectively without a debugger? Any advice would be appreciated. Can I use regular projects as my test ground ?
Optional map is also very useful when you want to pass the non-nil value to a function, otherwise keep the nil: let width = Float(widthTextField.text ?? “”).map { currentLengthUnit.toMeters($0) } ?? nil
i agree with you on the force unwrap example. other example might be the IBOutlets.. they already come with a force unwrap from Apple, because yes, you shold have those components. good video again Sean
even IBOutlets could be checked before unwrapped for example: @IBOutlets weak var titleLabel: UILabel! func viewDidLoad () { if let titleLabel { print(titleLabel) } } So force unwrap from Apple doesn't necessary mean you have to use without safety 😁
yeah, the thing is that the compiler only knows that the property is optional, so it could be null, so even though we know that some data needs to actually exist to, let's say, display a view, the compiler doesn't know that, so we can use the non-null assertion operator to bypass that case. Also we could simply put an if statement to check if the property is null => return; The guard let and if let seems to me like sintactic sugar because we could simple do the same without adding the keyword guard or the statement if let. if (myDataIsNull === null) return. The benefit i see from this is that you can read guard or if let and realize that this could be null or something lol
there’s stigma against force unwrapping optionals. Don’t be afraid of force unwrapping when you expect a non-nil value at point of accessing the variable. Running if-lets because “you don’t want the app crashing due to an edge case” will bite in future when debugging your code later if the app crash happens due to unexpected nil that’s a sign you need to fix the code itself; not the variable
I’m working with Dates and I see no reason to no force unwrap UNLESS I don’t know what date is coming through. Make 100% sure you know what date object is coming through and then make it happen.
Been coding for 40 years. Force unwrap is important to me and I use it all the time BC I want to know right when my code logic is invalid to result in an invalid nil. It does me no good to fail silently then later on find out that some variable was nil minutes ago. This is particularly true when designing/debugging. Then you’ll have some confidence that the code is “fully” functioning (does that ever really happen).
Force unwrapping is helpful with UIImage I’ve found. As long as the image asset name matches the string value, It has always worked in my case. Of course ?? is always there, but then you’ll be force unwrapping that default UIImage value regardless…
In the calendar code I would not use Calendar.current. I recently had to fix a crash related to this. Create a Calendar manually with the Gregorian identifier or you may get unknown behavior.
The issue is that the user may have a non-Gregorian calendar set
Good stuff! I frequently avoid the simple nesting logic issue at 2:30 by combining the tests in the if let (if let age = user.age, age > 40)
'm new to Swift and trying to solve some LeetCode problems in Xcode. I realized that I can't debug in Playgrounds, which makes it hard to see what I'm doing. How can I learn Swift effectively without a debugger? Any advice would be appreciated.
Can I use regular projects as my test ground ?
Thx
Optional map is also very useful when you want to pass the non-nil value to a function, otherwise keep the nil:
let width = Float(widthTextField.text ?? “”).map { currentLengthUnit.toMeters($0) } ?? nil
Yo you the man, Sean Allen. Thanks for explaining these things in easy nontechnical terms
Thank you for the great video! Helped me a lot :)
The "cache example" looks really interesting.
Maybe you could do a video about caching?
i agree with you on the force unwrap example. other example might be the IBOutlets.. they already come with a force unwrap from Apple, because yes, you shold have those components. good video again Sean
even IBOutlets could be checked before unwrapped
for example:
@IBOutlets weak var titleLabel: UILabel!
func viewDidLoad () {
if let titleLabel {
print(titleLabel)
}
}
So force unwrap from Apple doesn't necessary mean you have to use without safety 😁
yeah, the thing is that the compiler only knows that the property is optional, so it could be null, so even though we know that some data needs to actually exist to, let's say, display a view, the compiler doesn't know that, so we can use the non-null assertion operator to bypass that case.
Also we could simply put an if statement to check if the property is null => return; The guard let and if let seems to me like sintactic sugar because we could simple do the same without adding the keyword guard or the statement if let.
if (myDataIsNull === null) return.
The benefit i see from this is that you can read guard or if let and realize that this could be null or something lol
So 40 is old now huh lol.
there’s stigma against force unwrapping optionals. Don’t be afraid of force unwrapping when you expect a non-nil value at point of accessing the variable. Running if-lets because “you don’t want the app crashing due to an edge case” will bite in future when debugging your code later
if the app crash happens due to unexpected nil that’s a sign you need to fix the code itself; not the variable
I’m working with Dates and I see no reason to no force unwrap UNLESS I don’t know what date is coming through.
Make 100% sure you know what date object is coming through and then make it happen.
@Sean Allen : sir could you create video about restfull API in swift 5.7, thank you
Been coding for 40 years. Force unwrap is important to me and I use it all the time BC I want to know right when my code logic is invalid to result in an invalid nil. It does me no good to fail silently then later on find out that some variable was nil minutes ago. This is particularly true when designing/debugging. Then you’ll have some confidence that the code is “fully” functioning (does that ever really happen).
Thanks a lot! Usefull topic for both beginners and advanced. What about unwrap with compactMap and type casting (as?)
I would love for Rust to be a supported language for Apple development.
Wow! This is a tough topic for beginners but your delivery was awesome, hands down! Thank you so much for this !!
Great explanations as always, Sean!
Thanks Jason!
Good Stuff buddy!
Glad you enjoyed it, Bosch
👍👍👍
Thanks🙏🙏🙏🙏
👍👍👍👍👍
Force unwrapping is helpful with UIImage I’ve found. As long as the image asset name matches the string value, It has always worked in my case. Of course ?? is always there, but then you’ll be force unwrapping that default UIImage value regardless…