+1 Type narrowing would also fit nicely with union types (as demonstrated in Ceylon).
-Thorsten > Am 05.01.2016 um 23:37 schrieb Dennis Lysenko <dennis.s.lyse...@gmail.com>: > > That said, I am in favor of automatic type narrowing. As long as it doesn't > complicate the compiler considerably (if it does, there's little reason to > replace optional binding), it's no less confusing than shadowing was when I > first saw it, and once you get used to it (shouldn't be more than a day): it > is less verbose and perhaps more intuitive (I've found myself reacting to > optionals saying "duh, I've already guarded that X is nonnull on this > codepath, why would I have to unwrap it again?" in Swift). > >> On Tue, Jan 5, 2016 at 5:35 PM Dennis Lysenko <dennis.s.lyse...@gmail.com> >> wrote: >> Thorsten, >> >> Not that I disapprove (Kotlin does the same and it's great), the precedent >> seems to have already been set in people's minds that there won't be any >> kind of implicit type narrowing and I predict a fair few will respond with >> "You can already do that with optional binding, and I'm uncomfortable seeing >> a variable change type in an inner scope" even though shadowing achieves >> exactly the same aim. The same happened the last time that type narrowing >> was mentioned. >> >> >>> On Tue, Jan 5, 2016 at 5:27 PM Thorsten Seitz via swift-evolution >>> <swift-evolution@swift.org> wrote: >>> 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 >>>> <swift-evolution@swift.org>: >>>> >>>> >>>> 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 <cloutierty...@aol.com> 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 >>>>>> <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 >>> >>> >>> _______________________________________________ >>> 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
