I often find myself writing:
if let someVariable {
and then correcting it to:
if let someVariable = someVariable {
So I think this would be the best shortcut. It should at least be offered as a fix-it.
A ? suffix would makes sense in a deconstruction pattern, but the if let syntax isn't a deconstruction pattern.
Here, however, the repetition is load-bearing.
Others have mentioned above that the act of assignment is important to understanding the meaning of what’s going on, for which reason they find the presence of = to be useful. But consider also the clarifications earlier in this thread that what’s happening here is shadowing, which is notable and distinct from mere assignment to another variable.
In Swift, shadowing only occurs where the user deliberately chooses a new variable in a local scope with the exact name as a variable in the outer scope. Put another way, it is precisely the repetition of an identical name that is the shadowing. Omit so much as one letter, and shadowing doesn’t occur.
It is reasonable, certainly, to restate the problem here as desiring a shorthand for shadowing a variable without requiring such a brittle notation, but it is important to acknowledge that at present the repetition itself carries significant meaning that is not extraneous.
I think this is certainly a viable choice and maybe my favorite here so far:
It would be generalizable to shadowing a variable in the local scope independent of if let. (That is, one can imagine shadowing a function parameter, making a mutable copy, by writing func f(_ x: Int) { var shadow x; . . . }.)
It naturally reveals, without the need for additional explanatory text, why scenarios such as let shadow x.y don’t work (for the same reason that let x.y = x.y doesn’t work).
It allows IDEs to provide proper autocomplete (after the user types shadow) without also actively offering users existing variable names after every let that they type (which would be tantamount to actively encouraging shadowing at every turn, where users may not wish to do so, causing problems if a new user chooses a recommended name without understanding that they’ve just shadowed a variable they may want to access later).
If that is the definition of shadowing (that the name is the same), then I'm not sure the brittleness of that is very relevant. I have never found myself desiring to shadow (by that definition), the situation is always that you have something that is optional, and you want to be able to use it as if it was non-optional, provided it is non-nil.
Maybe this is just splitting hairs, but my point is that focusing specifically on shadowing seems to miss the broader issue here.
--- EDIT: added
And I do agree with you initial point, that the repetition serves a purpose.
It seems to me that repeating a potentially long variably name is a minor inconvenience. The refactor issue is purely a tooling issue (I mean, doesn't "rename" already offer to rename variable names in comments?)
In my own code, if let x = x is probably less common than if let x = y.x and if let x = makeX(), but I'm not sure that the solution must cover those cases. It can't really be said that there is any unnecessary repetition there, and it seems difficult to come up with a solution that doesn't seem very magical.
Shortening if let x = x to if let x is pretty straightforward, with x.y it's less so. And with makeX(), perhaps the most common case, I'm not sure there is any good solution.
You don't have to imagine it:
func f(x: Int) {
print(x) // 3
var x = x
x = 15
print(x) // 15
}
f(x: 3)
This has already been explored earlier in this thread. The mechanism by which one accomplishes the use of a variable that’s unwrapped by the same name as the wrapped variable is shadowing. There is no broader issue here unless you suppose that it is possible to propose some alternative that can be justified alongside (not replacing) shadowing and somehow not be more confusing.
To be clear, I am imagining the use of the suggested syntax in this scenario (that is, outside of an ‘if’ expression). I am fully aware of how to use Swift as it is.
My point was just that for me it doesn't matter that if let myValue = myValue is shadowing, while if let myVal = myValue isn't, so it doesn't seem like an issue that refactoring can easily turn shadowing into non-shading for example.
Then I don't understand the point of the proposal. Why propose sugaring that works in a specific circumstance (i.e. you want to shadow a variable of the exact same name), when we already have a syntax that works in every situation?
And what is it about shadow that would imply Optional<T> -> T ?
I understand that if let x = x does not necessarily imply that mapping either, but at least it did not introduce new syntax. Introducing a new keyword that doesn't even imply its primary purpose seems a rather poor idea.
It answers the concern that if the variable-to-be-shadowed is renamed, then such a refactoring would cause that variable no longer to be shadowed, for the same reason that being even one letter mismatched would cause shadowing not to occur.
Given this problem statement, then an appropriate solution is a new syntax that makes explicit the desire to shadow and that does not require repeating the name of the variable-to-be-shadowed exactly.
Absolutely nothing about shadow suggests that it unwraps, nor should it. This is why I like how it addresses the stated problem so much: it is orthogonal to unwrapping entirely and can be used elsewhere in scenarios where shadowing is desired.
It is the if let that specifically indicates unwrapping, and the proposed shadow composes nicely with that without introducing any new syntax for unwrapping.
Precisely. See the discussion earlier: based on that back-and-forth, my analysis of the problem is that the true issue in need of solution is the repetition necessary to shadow, and the virtue of this solution is that it actually solves that problem explicitly rather than hitching it to unwrapping, which is served efficiently by if let and related constructs and has nothing to do with the problem of repetition.
I still don't think brittle refactoring is an issue, but I agree that if let shadow makes a lot of sense, since it avoids the repetition in a semantic way, by saying that you want the unwrapped variable to shadow the original. Best suggestion so far.
As I mentioned up-thread, capture list syntax is a counterexample to this general rule, since { [x] in ... } implicitly shadows x in the closure scope without any repetition (or, indeed, even an indication that a new variable is being introduced at all).
It's a perfectly reasonable position that this edge case is a 'bad' part of the language that we shouldn't emulate elsewhere, I just wanted to emphasize that there is precedent for optimizing for the x = x case in situations where shadowing is likely. Granted, I suspect that "capture variable using the same same" is the vast majority of capture use cases, whereas for if let the "unwrap to variable with the same name" is merely a somewhat common use case, so the "win" for optimizing this syntax is considerably smaller than for capture lists.
I wouldn’t say it’s a ‘bad’ part of the language, but there’s several salient differences:
let either: this answers the concern that let x already has a meaning in that it declares a variable to be initialized later[x] in … as “captures x in…”—and by the same token, we are discussing what it takes to provide a similar context hereI find the premise of the discussion hard to follow. The problem seems to be that toolings cannot recognize the intent of shadowing in a scenario where one shadows a variable via if-let syntax.
If that's the case, improving tooling is also a viable solution that doesn't even require language changes, including other auto-complete structures, like typing if let = gives you variable name suggestion, and/or also refactor the LHS of the assignment if they match the RHS.
Then the discussion threw me a curveball by talking about programmers using terser variable names, which wouldn't benefit from any of the solutions/syntaxes discussed thus far. In fact, it seems to be the exact scenario where they poorly fit. If one is to shorten the variable name anyhow, then forcing them to use shadowing would lengthen the code inside the block, almost unnecessarily:
if let x = someLongVariableName {
x...
x...
}
if shadow someLongVariableName {
someLongVariableName...
someLongVariableName...
}
I think the let keyword is important here (or var) and strongly prefer this spelling:
if let x { ... }
It is simple short-hand for
if let x = x { ... }
And it solves the problem in the original post.
I don't feel that it needs to work with:
if let other?.x { ... }
In that case we can just require the developer to write it out and choose the variable name:
if let x = other?.x { ... }
To be clear, I don't know if there is actually a use for deferred optional binding (there probably isn't), but I just wanted to illustrate that when I see let or var without a nearby =, I tend to think "deferred assignment". I suppose one exception here already is extracting associated values in a switch statement...
Yes! I think this is perfect:
if fooViewController? { fooViewController.view ... }
The ? makes it intentional and it handles nullable Bools quite elegantly.
I think using let x syntax would be a mistake, although I certainly see the appeal. The reason is that let x with no explicit assignment on the right-hand side already has a meaning in Swift, namely as a way to do assignment via pattern matching.
enum Foo {
case baz(Int?)
}
let myFoo: Foo = .baz(42)
switch myFoo {
case .baz(let x): // this `let x` does not unwrap
print(type(of: x)) // Optional<Int>
if let x { // this (hypothetical new syntax) ‘let x` unwraps
print(type(of: x)) // Int
}
default: break
}
I think it will be confusing to language learners that let x sometimes strips away optionality and sometimes doesn’t. I’m speaking as someone who learned Swift in the past few years after not having done any real programming since RealBasic on the classic Mac.
If this needs to be done at all, my preference would be for if let x? which, while it does overload ?, at least does so with a meaning that has the same semantical vibe as ? in optional chaining—i.e. ‘continue to process what’s coming if x is non-nil.’
I find the original syntax perfectly readable.
if let foo = foo {}
The left foo is non-optional and has more local scope than the right foo. The lack of autocomplete is a minor annoyance (thanks to cut-and-paste) and does not warrant adding another keyword like:
if have foo {}
And I'd be very unhappy with more magic around the ? symbol:
if foo? {}
So while I thank Craig for his pitch, I'll simply say I respectfully oppose either of his proposed changes.
Darrell
I've grown to love if let (and guard let) after initially feeling like you mostly because I see that it really makes me focus on good error handling. By being forced to unwrap it this way, you're forced to think of null situations. Having recently had to go back to some old Objective-C code, I really appreciate this.
Also there are many cases where I will chain multiple options with a if let. Consider, for example, a User struct and you want to get their profile photo from their profile. You can simply write code like:
if let profileURL = user.profile?.imageURL { }
Here both profile and imageURL can be optional.
Let If Let Be.
I always thought it was the if that did the unwrapping. If that's not the case, why require if at all, might as well just allow let x? { // use x here. } at that point right?