<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><blockquote type="cite" class=""><div class="">On Oct 26, 2016, at 8:58 AM, Erica Sadun via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class="">On Oct 26, 2016, at 5:40 AM, David Goodine 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=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Hey all,</div><div class=""><br class=""></div><div class="">As usual, apologies if this horse was beaten ages ago before I joined the mailing list, but thought I would bring this up.</div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>Yes, this has thoroughly been beaten to death. It is also outside the scope of Swift 4 stage 1. That said, it is such a glaring problem that we’ll have to deal with it at some point.</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">I was typing the above (for the hundredth time) the other day and I was wondering whether it might be worth considering offering a shorter syntax:</div><div class=""><br class=""></div><div class=""><font face="Courier" class="">guard let x, y, z else {…}</font></div></div></div></blockquote></div></div></div></blockquote><div><br class=""></div><div>This specific syntax is commonly requested. The problem with this is that it provides no useful information about what is actually going on: it sacrifices clarity to get terseness, a specific non-goal of Swift.</div><div><br class=""></div><div><br class=""></div>Erica says:<br class=""><blockquote type="cite" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">Your initial suggestion doesn't work as overloading "let" confuses rather than clarifies this process. In February, I brought up `bind x` to mean "conditionally bind x to x, and produce a conditional fail if that's not possible", with the hope that "bind self" could be used in closures. Under that scheme your example would read:</div><div class=""><br class=""></div><div class="">guard bind x, bind y, bind z else { … }</div></div></blockquote><br class=""></div><div>To me, this is the most promising direction, but I’d suggest the use of “unwrap" as the keyword. If you compare these two:</div><div><br class=""></div><div>a) guard let foobar = foobar else { … }</div><div>b) guard unwrap foobar else { … }</div><div><br class=""></div><div>I think that b) wins by virtue of eliminating repetition ("foobar = foobar" fails DRY principles), but retains clarity by introducing a word into the grammar that people already commonly know and use, and which is googlable if they don’t.</div><div><br class=""></div><div>This also gives us the conceptual hook to make the “unwrapping an optional” behavior (which occurs with if let, optional chaining, etc) be something that could be extended to other similar user defined types, such as a Result type.</div><div><br class=""></div><div>-Chris</div><br class=""></body></html>