Cihat, if either of the two you proposed I would prefer "let foo?" as the bang (!), outside of logical negation, carries a meaning of "this is dangerous and something could go wrong at runtime here". Evidenced by its only other uses--try!, force-unwrapping, and implicitly unwrapped optionals.
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. On Sat, Dec 19, 2015 at 7:02 PM Cihat Gündüz <[email protected]> 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 < > [email protected]>: > > > On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution < > [email protected]> 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 < > [email protected]> 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 < > [email protected]> 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 < >> [email protected]> wrote: >> >> >> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution < >> [email protected]> 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 >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > -Dave > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
