I've always thought that, if let foo = foo? {
} makes more sense than if let foo = foo { } as the ? indicates that you are unwrapping the optional and then assigning it to the new variable > On Dec 19, 2015, at 7:02 PM, Cihat Gündüz via swift-evolution > <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