@Kevin: That is why I'm suggesting if unwrap foo {, because I believe it's clearer than either. I was trying to say, though, that "if let foo = bar", one of the first things you learn in swift, transitions naturally to "if let foo = foo", though slightly disorienting at first, but will be disconnected from just "if let foo" due to being in a fundamentally different format.
@Cihat: Aha, interesting points. I still think a more explicit keyword like "unwrap" or "bind" would achieve a bit more clarity. On Sat, Dec 19, 2015 at 7:47 PM Cihat Gündüz <cihatguend...@posteo.de> wrote: > However, you may be interested in the last email Chris sent in this chain > with regards to shortening it to just "let foo": > > "This is commonly requested - the problem is that while it does help > reduce boilerplate, it runs counter to the goal of improving clarity." > > He's got a point; "if let foo = bar" makes sense in a way, but just "if > let foo" is a bit nonsensical to me when I take my mind outside of the > narrow swift mindset I tend to get into. This extends to decorating the foo > with a question mark or a bang, imo. > > > Thank you for the feedback, Dennis. That post you quote is amongst the > ones I read and it is even the reason I am suggesting these alternatives. > Let me explain my thinking behind my suggestions a bit. I agree with Chris > that `if let foo { /* code */ }` isn’t very readable mainly because there > is no action done on the `foo` like a `= bar` or something else. But I also > had the thought ‚why do I need to type this twice, can’t this be > optimized?‘ quite a few times when I used `if let foo = foo { /* code */ }` > in practice. > > So that’s why I thought there must be a way. First I started with > something that contained the `=` sign also using the shorthand `x += 1` for > `x = x + 1` as an inspiration. That lead to things like these: > > if let foo = _ { /* code */ } > if let foo = ! { /* code */ } > if let foo ?= _ { /* code */ } > if foo ?= foo { /* code */ } > if let foo ?= { /* code */ } > > But being honest to myself I thought all of those were even less readable > then `if let foo { /* code */ }`. But once I dropped the `=` sign like in > `if let foo! { /* code */ }` I started to like the idea and still found it > readable. > > I generally read let like a ‚define constant with name‘ and a ! like > ‚force unwrap value‘ so I would read `let foo!` as ‚define constant with > name and force unwrap value`. But I agree that ? may be more correct which > I read as `try to unwrap value only continuing if unwrap succeeds` so `let > foo?` would read as `define constant with name and try to unwrap only > continuing if unwrap succeeds`. > > So in conclusion to me `if let foo { }` isn’t readable but `if let foo? { > }` is. That is only my opinion though. > > > On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <swift-evolution@swift.org> > wrote: > >> I’ve only read the last couple of posts but has anybody already suggested >> using something like this: >> >> if let foo! { >> // code that uses foo >> } >> >> People already know that the ! is unwrapping a value and that let is >> defining a new constant. So why not combine those two? >> Alternatively it could also be: >> >> if let foo? { >> // code that uses foo >> } >> >> What do you think? >> >> – Cihat >> >> Am 19.12.2015 um 23:43 schrieb Dave Abrahams via swift-evolution < >> swift-evolution@swift.org>: >> >> >> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> I was going to suggest something similar (a hard naming problem also): >> >> if has foo { >> // foo is now unwrapped and non-optional >> } >> >> guard has foo else { return } >> >> Does the same thing as `let foo = foo` in practice, but places it in a >> somewhat different mental model. Instead of unwrapping and immediately >> assigning to a new constant with the same name (which just looks kind of >> silly, like some magic voodoo ritual), it sort of asserts that we “have” >> foo (i.e. it’s not nil), and therefore from that point it can just be >> treated as non-optional. >> >> IMHO this, although introduces a new keyword, makes more sense than >> trying to reuse “let” in a context where it seems nonsensical. Perhaps this >> would be closer to Swift’s goals, by reducing very common boilerplate, but >> without harming clarity in a way adding a new meaning to “let” would. >> >> Curious to hear Chris Lattner’s opinion :-) >> >> >> IANACL (I am not a Chris Lattner) but, FWIW, several of us are >> uncomfortable with the idea that a single declared property might have >> different static types in different regions of code. >> >> >> — Radek >> >> On 19 Dec 2015, at 21:31, Dennis Lysenko via swift-evolution < >> swift-evolution@swift.org> wrote: >> >> What if we made the keyword "unwrap"? >> >> if unwrap someViewController { >> // now there is a shadowing nonoptional (unwrapped) variable of the same >> name only within this scope, boiling down to simple syntactic sugar for >> optional binding and it is fairly clear. >> } >> >> On Sat, Dec 19, 2015, 1:31 PM Kevin Wooten via swift-evolution < >> swift-evolution@swift.org> wrote: >> >>> As much fun as it to example with foo, I would argue the opposite when >>> you use some real world variable names: >>> >>> if let someInterestingViewConroller = someInterestingViewConroller { >>> } >>> >>> vs >>> >>> If let someInterestingViewConroller { >>> } >>> >>> We know what let does and it should be enough to impart the necessary >>> information for this statement. >>> >>> When it comes to newcomers I think you'd be hard pressed to find >>> somebody who'd be able to understand either form without teaching; so not >>> losing much there. >>> >>> >>> On Dec 19, 2015, at 10:01 AM, Chris Lattner via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> >>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution < >>> swift-evolution@swift.org> wrote: >>> >>> I’ve had similar ideas to this. Instead of ditching the if let syntax >>> altogether, another approach would be to use the existing name if no new >>> name is given, so that this code: >>> >>> if let foo = foo { /* use foo */ } >>> >>> could become this code: >>> >>> if let foo { /* use foo */ } >>> >>> In both cases, foo is non-optional inside the braces. If you gave it >>> another name with the if let syntax, that would work as it does today. >>> >>> >>> Hi Jeff, >>> >>> This is commonly requested - the problem is that while it does help >>> reduce boilerplate, it runs counter to the goal of improving clarity. >>> >>> -Chris >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> -Dave >> >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution