I propose a shortened syntax for using if-let with local names unwrapping
higher order optionals of the same name. i. e.
if let a {
//code
}
as a shortcut for this:
if let a = a{
//code
}
From my observations echoing the local let variable name on the optional
being unwrapped seems to have become the commonly used practice.
I do not see this conflicting with any existing code.
My only thought's on potential pitfalls are if there is a local variable
and higher order variable both with the same name, as there may be
confusion as to which you are unwrapping. Although I don't see this as a
huge issue, as fault for such an error seems like it would weigh mostly on
architectural mistakes.
Also I think this would go hand in hand with a guard implementation of the
same nature
I believe that's a duplicate of "Proposal: Optional Binding Shorthand Syntax". Let me quote Chris Lattner on that:
Right.
“if let foo {“ is a frequently proposed extension to the syntax, but it is not one that we’re likely to ever add.
I agree that this is a common pattern, and it would allow you to “write less code”, but that isn’t the goal of Swift. Since code is read more often than it is written, the real goal behind Swift is to let you write “more readable code” by eliminating boilerplate and other noise.
Reducing syntax isn’t itself a goal, particularly if the result could/would be confusing for someone who has to read and maintain your code later.
-Chris
Pozdrawiam – Regards,
Adrian Kashivskyy
···
Wiadomość napisana przez Richard Fox <fox.ios.dev@gmail.com> w dniu 04.12.2015, o godz. 00:13:
Hi all,
I propose a shortened syntax for using if-let with local names unwrapping higher order optionals of the same name. i. e.
if let a {
//code
}
as a shortcut for this:
if let a = a{
//code
}
From my observations echoing the local let variable name on the optional being unwrapped seems to have become the commonly used practice.
I do not see this conflicting with any existing code.
My only thought's on potential pitfalls are if there is a local variable and higher order variable both with the same name, as there may be confusion as to which you are unwrapping. Although I don't see this as a huge issue, as fault for such an error seems like it would weigh mostly on architectural mistakes.
Also I think this would go hand in hand with a guard implementation of the same nature
guard let a else{
//code
}