Well, &quot;guard x != nil&quot; does not unwrap x. An additive proposal must make clear the difference between testing if an optional is nil and unwrapping it.<br><br>Meanwhile, &quot;guard foo&quot; tests if foo evaluates to true. An additive proposal cannot break this syntax.<br><div class="gmail_quote"><div dir="ltr">On Mon, Oct 31, 2016 at 14:11 Charlie Monroe &lt;<a href="mailto:charlie@charliemonroe.net">charlie@charliemonroe.net</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">To me, it makes more sense to use</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">guard nonnil x else ...</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">since guard is guarding a condition is true - or am I wrong? Generally, it would tell the compiler that</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">guard x != nil else ...</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">which to me reads like guard nonnil x...</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Just a side-note... </div></div><div style="word-wrap:break-word" class="gmail_msg"><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Oct 31, 2016, at 8:05 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br class="m_-4179006634048633020Apple-interchange-newline gmail_msg"><div class="gmail_msg">The proposal is to create a new shorthand &quot;guard unwrap x&quot; for &quot;guard let x = x&quot;. The &quot;guard&quot; statement serves purposes other than unwrapping variables and cannot be removed.<br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Oct 31, 2016 at 14:03 Joshua Alvarado &lt;<a href="mailto:alvaradojoshua0@gmail.com" class="gmail_msg" target="_blank">alvaradojoshua0@gmail.com</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class="gmail_msg"><div class="gmail_msg">Without going back through the history, is the proposal to keep replace guard or still keep guard keyword and create a new unwrap? If unwrap is added the guard keyword should just be removed. </div></div><div dir="auto" class="gmail_msg"><div id="m_-4179006634048633020m_-1340813727907140397AppleMailSignature" class="gmail_msg"><br class="gmail_msg">Alvarado, Joshua</div></div><div dir="auto" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg">On Oct 31, 2016, at 12:49 PM, Xiaodi Wu via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"><br class="gmail_msg"></div><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">Because &quot;guard&quot; already means something...<br class="gmail_msg"><br class="gmail_msg"><br class="gmail_msg"><div class="gmail_quote gmail_msg"><div dir="ltr" class="gmail_msg">On Mon, Oct 31, 2016 at 13:45 Kenny Leung via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg"></div><blockquote class="gmail_quote gmail_msg" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">It seems to me that you would end up typing “guard unwrap” 99% of the time, so why not just let “guard” imply “guard unwrap” 100% of the time?<br class="gmail_msg">
<br class="gmail_msg">
-Kenny<br class="gmail_msg">
<br class="gmail_msg">
<br class="gmail_msg">
&gt; On Oct 31, 2016, at 11:34 AM, Erica Sadun &lt;<a href="mailto:erica@ericasadun.com" class="gmail_msg" target="_blank">erica@ericasadun.com</a>&gt; wrote:<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; Because there&#39;s an action taking place in addition to guarding<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt; -- E<br class="gmail_msg">
&gt;<br class="gmail_msg">
&gt;&gt; On Oct 31, 2016, at 12:30 PM, Kenny Leung via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt; Why have the “unwrap” keyword at all? Isn’t “guard” the keyword?<br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt; guard blah else {<br class="gmail_msg">
&gt;&gt; }<br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt; -Kenny<br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; On Oct 28, 2016, at 3:34 PM, Erica Sadun via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt; On Oct 26, 2016, at 11:39 AM, Chris Lattner via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>&gt; wrote:<br class="gmail_msg">
&gt;&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt;&gt; On Oct 26, 2016, at 10:23 AM, Joshua Alvarado &lt;<a href="mailto:alvaradojoshua0@gmail.com" class="gmail_msg" target="_blank">alvaradojoshua0@gmail.com</a>&gt; wrote:<br class="gmail_msg">
&gt;&gt;&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt;&gt; In your example the keyword only makes sense if you are shadowing the optional variable. How would unwrap work with a different name?<br class="gmail_msg">
&gt;&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt; It wouldn’t: “unwrap” would never include an equal sign.  If you want to do that, use a standard &quot;if let”.<br class="gmail_msg">
&gt;&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;&gt; -Chris<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; So I can stop thinking about this. Gist is here: <a href="https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c" rel="noreferrer" class="gmail_msg" target="_blank">https://gist.github.com/erica/db9ce92b3d23cb20799460f603c0ae7c</a><br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; -- E<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Introducing unwrap<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;     • Proposal: TBD<br class="gmail_msg">
&gt;&gt;&gt;     • Author: Erica Sadun, Chris Lattner, David Goodine<br class="gmail_msg">
&gt;&gt;&gt;     • Status: TBD<br class="gmail_msg">
&gt;&gt;&gt;     • Review manager: TBD<br class="gmail_msg">
&gt;&gt;&gt; Introduction<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; This proposal introduces unwrap, simplifying common shadowing and allowing a unified syntax for one-item associated values such as Result types.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Swift-evolution thread: guard let x = x<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Motivation<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Swift lacks a unified, safe way to bind an optional or single-value enumeration to a shadowed varaiable that is guaranteed to be the same name. Introducing unwrap ensures the conditionally bound item does not accidentally shadow any other item.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Compare:<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard let foobar = foobar else { …<br class="gmail_msg">
&gt;&gt;&gt; }<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard unwrap foobar else { … }<br class="gmail_msg">
&gt;&gt;&gt; Using unwrap eliminates repetition (&quot;foobar = foobar&quot; fails DRY principles) and retains clarity. The keyword is common, simple to understand, and easy to search for if Swift users are unfamiliar with it.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; This syntax simplifies one-item associated value enumerations by offering a common syntax. Compare:<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; enum Result&lt;T&gt; { case success(T), error(Error<br class="gmail_msg">
&gt;&gt;&gt; ) }<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard case let .success(value) = result else { ...<br class="gmail_msg">
&gt;&gt;&gt; }<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard unwrap result else { ... }<br class="gmail_msg">
&gt;&gt;&gt; In the latter case result is bound to the wrapped value. Again, it is simpler and clearer, even with non-Optional types.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Detailed Design<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; unwrap can be used with any one-value enumeration. The unwrapped value is bound to the same symbol as the associated type.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; enum TypeName&lt;T, U&gt; { case anycase(T), anothercase(U) }<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; // First and second are type `TypeName`<br class="gmail_msg">
&gt;&gt;&gt; let first = TypeName.anyCase(value1)<br class="gmail_msg">
&gt;&gt;&gt; let second = TypeName. anothercase(value2)<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard unwrap first else { ... }<br class="gmail_msg">
&gt;&gt;&gt; // first is now shadowed as type T<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; guard unwrap second else { ... }<br class="gmail_msg">
&gt;&gt;&gt; // second is now shadowed as type U<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Impact on Existing Code<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; This change is additive and has no impact on existing code other than intentional refactoring.<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Timeline<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; This proposal is additive and not suited for consideration until Swift 4 phase 2<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; Alternatives Considered<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt;     • Using a bind keyword. Past discussions were held in the first week of February 2016.<br class="gmail_msg">
&gt;&gt;&gt;     • Fixing pattern matching grammar<br class="gmail_msg">
&gt;&gt;&gt;     • Not using this approach<br class="gmail_msg">
&gt;&gt;&gt;<br class="gmail_msg">
&gt;&gt;&gt; _______________________________________________<br class="gmail_msg">
&gt;&gt;&gt; swift-evolution mailing list<br class="gmail_msg">
&gt;&gt;&gt; <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
&gt;&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
&gt;&gt;<br class="gmail_msg">
&gt;&gt; _______________________________________________<br class="gmail_msg">
&gt;&gt; swift-evolution mailing list<br class="gmail_msg">
&gt;&gt; <a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
&gt;&gt; <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
&gt;<br class="gmail_msg">
<br class="gmail_msg">
_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>
</div></blockquote><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><span class="gmail_msg">_______________________________________________</span><br class="gmail_msg"><span class="gmail_msg">swift-evolution mailing list</span><br class="gmail_msg"><span class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a></span><br class="gmail_msg"><span class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class="gmail_msg"></div></blockquote></div></blockquote></div>
_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></blockquote></div><br class="gmail_msg"></div></blockquote></div>