Disagree. I’ve seen people write things like the following:
if x != nil { x!.foo() }
and then later the x != nil condition is changed to no longer check for nil, or the x!.foo() is moved out of that lexical scope elsewhere, or copypastad, and then the force unwrap crashed. I’ve seen similar yet more subtle bugs with soft unwraps instead of forced: x?.foo()
Not possible if you use if let y = x . If you copypasta the inner scope with the different variable name then it won’t compile.
(ofc these are trivial representative examples, in reality these were lexical scopes with many lines and more complicated code)
It’s not just about how the code looks when you write it, it’s the paths that can be taken by future maintenance programmers.
I‘ve complained about the large surface area of swift syntax, stdlib etc in the past, but I don’t personally find this specific thing confusing.
Disagree. I’ve seen people write things like the following:
and then later the x != nil condition is changed to no longer check for nil, or the x!.foo() is moved out of that lexical scope elsewhere, or copypastad, and then the force unwrap crashed. I’ve seen similar yet more subtle bugs with soft unwraps instead of forced: x?.foo()Not possible if you use if let y = x . If you copypasta the inner scope with the different variable name then it won’t compile.
(ofc these are trivial representative examples, in reality these were lexical scopes with many lines and more complicated code)
It’s not just about how the code looks when you write it, it’s the paths that can be taken by future maintenance programmers.
I‘ve complained about the large surface area of swift syntax, stdlib etc in the past, but I don’t personally find this specific thing confusing.