<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=""><div class="">Meta-comments:</div><div class=""><br class=""></div><div class="">"if let y = x { … } “ actually corresponds closest to</div><div class=""><br class=""></div><div class="">if x != nil {</div><div class=""> let y = x!</div><div class=""> …</div><div class="">}</div><div class=""><br class=""></div><div class="">e.g. has the following behaviors:</div><div class="">1. a comparison to nil</div><div class="">2. a copy of the reference or value w/o optionality</div><div class="">3. execution of a block</div><div class=""><br class=""></div><div class="">but also:</div><div class="">4. implication that this is safe within the block (my eyes would be drawn to that "let y = x!” every time)</div><div class="">5. ability to shadow outer optional variable with non-optional inner variable (e.g. if let x = x { … } )</div><div class=""><br class=""></div><div class="">You could do all of this of course via .flatMap, but there is an obvious desire for something closer to the traditional/familiar syntax of a conditional. </div><div class=""><br class=""></div><div class="">Having a special case of variable assignment within a conditional that casts off optionality feels odd, and I can understand why people have proposed changes. However, the proposals so far seem to have gotten hung up around point #2, having issues with either:</div><div class=""><br class=""></div><div class="">a) making it less clear that a copy is being made,</div><div class="">b) making it less clear that a copy is shadowing the original value, and/or</div><div class="">c) changing the capabilities of the actual statement, such that a copy is *not* being made, and the original value is effectively inout. This means that you are not actually replacing all uses of the syntax at all, but instead defining a new kind of operation.</div><div class=""><br class=""></div><div class="">Issues with a) and b) are syntactic. We can possibly come up with a more clear way to explain the current behavior, although its very hard to make it more clear that a copy is being made than a ‘let’ declaration and assignment. </div><div class=""><br class=""></div><div class="">Issues with c) are mostly just around clarity of purpose - you are defining something new, and "if let x = x” will likely still exist because uses for that operation are still likely valid.</div><div class=""><br class=""></div><div class="">-DW</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On Feb 1, 2016, at 12:18 PM, Erica Sadun 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=""><meta http-equiv="Content-Type" content="text/html charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">Joe says "<span style="font-family: Palatino-Roman;" class="">If you all are serious about this, I think you should start a new thread about it." </span><div class="">I think it's worth a serious discussion just so it can be evaluated and either adopted or discarded</div><div class="">and dropped forever. Here goes.</div><div class=""><br class=""></div><div class="">INTRO</div><div class=""><br class=""><div class="">The <font face="Menlo" class="">if let x = x {...}</font> and <font face="Menlo" class="">guard let x = x else {...}</font> constructs do something with <font face="Menlo" class="">let</font> (and <font face="Menlo" class="">var</font>) that's </div><div class="">fundamentally different from <font face="Menlo" class="">let</font> (and <font face="Menlo" class="">var</font>) elsewhere in the language. The same keywords are used to conditionally unwrap</div><div class="">and bind an item, not just shadow that item's current value.</div><div class=""><br class=""></div><div class="">Introducing a new <font face="Menlo" class="">bind</font> keyword to indicate unwrapping and binding would disambiguate these uses.</div><div class=""><br class=""></div><div class="">DETAIL DESIGN:</div><div class=""><br class=""></div><div class="">Jacob Bandes-Storch offers two common use-cases. I prefer his "if bind foo" to my original "if bind foo = foo":</div><div class=""><br class=""></div><div class=""><div class=""><font face="Menlo" class=""> if bind foo {</font></div><div class=""><font face="Menlo" class=""> // foo is non-optional in here</font></div><div class=""><font face="Menlo" class=""> }</font></div><div class=""><font face="Menlo" class=""><br class=""></font></div><div class=""><font face="Menlo" class=""> somethingAsync { [weak self] in</font></div><div class=""><font face="Menlo" class=""> guard bind self else { return }</font></div><div class=""><font face="Menlo" class=""> // ...</font></div><div class=""><font face="Menlo" class=""> }</font></div></div><div class=""><br class=""></div></div><div class="">JBS's approach offers my original "bind" keyword to unwrap and shadow bind, but also provides a way to </div><div class="">strongly bind a weak reference to self, which (presumably) would allow self semantics in the remaining</div><div class="">lifetime of that scope.</div><div class=""><br class=""></div><div class="">ALTERNATIVE PROPOSALS:</div><div class=""><br class=""></div><div class="">Tino Heth proposes a second use-case one with different semantics. This case, it seems to make an</div><div class="">alias rather than using binding for shadowing:</div><div class=""><br class=""></div><div class=""><font face="Menlo" class="">bind x = a.property.with.a.long.path<br class="">print x // 42<br class="">print(a.property.with.a.long.path == 42) => true</font></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><span style="font-family: Palatino-Roman;" class="">presumably this means:</span></div><div class=""><span style="font-family: Palatino-Roman;" class=""><br class=""></span></div><div class=""><font face="Menlo" class="">x += 1</font></div><div class=""><font face="Menlo" class="">print(a.property.with.a.long.path) // 43</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class="">DISCUSSION</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class="">I'm throwing these both out there. I have nothing to really say about Tino's but I do think my and Jacob's </font></div><div class=""><font face="Palatino-Roman" class="">proposal has the advantages of:</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class="">* Simplifying an mildly complex and potentially misleading statement </font></div><div class=""><font face="Palatino-Roman" class="">* Creating a deliberate and controlled rather than accidental shadowing style</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class="">Have at it.</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class="">-- Erica</font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div><div class=""><font face="Palatino-Roman" class=""><br class=""></font></div></div>_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></body></html>