<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">Le 14 nov. 2016 à 10:10, Haravikk <<a href="mailto:swift-evolution@haravikk.me" class="">swift-evolution@haravikk.me</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On 13 Nov 2016, at 16:16, Jean-Daniel via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" class=""><div class=""><br class="Apple-interchange-newline">Le 13 nov. 2016 à 03:37, Dennis Lysenko via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> a écrit :</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">That's a good point in Jay's example and from what I can tell a good way to address it, Haravikk. <div class=""><br class=""></div><div class="">I've done some work in a language that only provides type narrowing for immutable types (that'd be Kotlin as I've mentioned before) and whenever I've used it it feels like the only thing it's really been missing is the "if let" construct allowing you to bind and unwrap mutable values, which leads me to think that synergistically, in Swift, this would be fantastic. The main benefit probably is that it would allow code to read much better.</div></div></div></blockquote><div class=""><br class=""></div>IMHO, the Kotlin solution is flaw. The fact that type narrowing does not works for var and that there is no simple way to unwrap optional just force the developer either to introduce local variable, or to use the force unwrap operator.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Moreover, introducing a unwrap syntax (if let) like in swift would just result in having 2 different and inconsistent way to do the same thing.</div></div></blockquote><br class=""></div><div class="">I'll have to take a closer look at how Kotlin does this when I get a chance, but how would this affect the two proposals as they currently stand?</div><div class=""><br class=""></div><div class=""><a href="https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md" class="">https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-type-narrowing.md</a></div><div class=""><a href="https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md" class="">https://github.com/Haravikk/swift-evolution/blob/master/proposals/NNNN-optional-unwrapping.md</a></div><div class=""><br class=""></div><div class="">These keep automatic narrowing of polymorphic types, but requires explicit narrow/unwrapping of optionals (because we can define methods/properties on Optional there's no other choice unfortunately); it would work for both mutable and immutable values, but mutable reference types require an extra step due to the potential for unsafe operations.</div><div class=""><br class=""></div><div class="">I think that's about as flexible as we're going to be able to get without introducing other difficulties.</div></div></div></blockquote></div><br class=""><div class="">While the proposals try to be less restrictive than Kotlin, I don’t like the way they handle concurrency.</div><div class="">All usage of the ‘!’ operator in swift guarantee a crash at the call site if something is wrong (try!, as!, optional!, …). In the proposals, the ‘!’ operator means that the app may crash at call site or may crash later.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>