Ceylon has type narrowing (not only for optional unwrapping but for type checks as well): http://ceylon-lang.org/documentation/1.2/tour/types/#narrowing_the_type_of_an_object_reference
It always struck me as quite natural to do this. -Thorsten > Am 02.01.2016 um 06:08 schrieb Tyler Fleming Cloutier via swift-evolution > <[email protected]>: > > > Whoops, errant button tap. > > 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. > > The current syntax must seem incomprehensible/redundant to those new to > Swift. This obviously doesn't help with the verbosity at all, but it seems to > be more consistent with ? being the operator for unwrapping. > > Of course there is also the current optional pattern matching syntax: > > if case let foo? = foo { > > } > > This accomplishes the same thing and is somewhat less perplexing than "if let > foo = foo", but must still be baffling to a new user. > > You could even have: > > if foo? { > foo.blah() > } > > Which would not create a shadow local variable but would have the same > semantics as > > foo?.blah() > > in that is just providing conditional access to the variable if it's not > .None. Not sure if this direct access is desired as it is still magical > scoped type manipulation without declaring a new variable. > > > Tyler > > >> On Jan 1, 2016, at 11:44 PM, Tyler Cloutier <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 >> <[email protected] <mailto:[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] <mailto:[email protected]>>: >>>> >>>>> >>>>> On Dec 19, 2015, at 2:15 PM, Radosław Pietruszewski via swift-evolution >>>>> <[email protected] <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[email protected]>> wrote: >>>>>> >>>>>>> >>>>>>>> On Dec 11, 2015, at 8:19 AM, Jeff Kelley via swift-evolution >>>>>>>> <[email protected] <mailto:[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] <mailto:[email protected]> >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> [email protected] <mailto:[email protected]> >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>>> >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> [email protected] <mailto:[email protected]> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> -Dave >>>> >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> [email protected] <mailto:[email protected]> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > [email protected] <mailto:[email protected]> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
