<div>In Rust lang, it uses .unwrap and b can be a non-nil variable.</div><div><br></div>guard a.unwrap, b, c.unwrap else {<div>}<br><br>On Tuesday, November 1, 2016, Nicholas Maccharoli via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">I like the idea of drying up something like `guard let x = x, let y = y, let z = z else { return }`</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">Using `guard unwrap` would surely be an improvement but still maybe something like `guard unwrap x, unwrap y, unwrap x else { return }`</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">although very clear in intent is a bit bulky.</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">What about something like introducing a `given` / `given-where` clause for `if` and `guard` ensuring an optional is non-nil and shadowing the variable with an unwrapped variable of the same name.</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">one way might be:</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">guard given a, b, c else { return }</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">or with an attached conditional:</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">guard given a, b, c where a > b else { return }</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">for dealing with long if-lets you could do something like:</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">if given a, b, c where a > b { ... }</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">Instead of if let a = a, b = b, c = c, a > b { ... }</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">The `where` clause does not need to be an actual keyword, it can just be a trailing boolean expression but</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">maybe having it makes things like unwrapping and testing that a variable evaluates to `true` more distinguishable.</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">something like `if given a, b, c, c { ... }` looks like it could be an accidental typed repeat of `a` as much as it could mean `if given a, b, c, c == true { ... }`</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">`if given a, b, c where c { ... }` might read a little easier.</div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">Just a thought. </div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13">- Nick </div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div><div class="gmail_default" style="font-family:comic sans ms,sans-serif;color:#274e13"><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Nov 1, 2016 at 4:26 PM, Goffredo Marocchi via swift-evolution <span dir="ltr"><<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Agreed, a change like this would make sense :).<br>
<br>
Sent from my iPhone<br>
<div><div><br>
> On 1 Nov 2016, at 01:58, Joe Groff via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
><br>
><br>
>> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <<a href="javascript:_e(%7B%7D,'cvml','xiaodi.wu@gmail.com');" target="_blank">xiaodi.wu@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution <<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a>> wrote:<br>
>> Sorry for piling onto the bikeshed. We do already have a notation for testing that an Optional isn't nil, `x != nil`. We could theoretically bless `<decl ref> != nil` as a statement condition to also unwrap the referenced declaration in the scope guarded by the condition. (`<decl ref> is T` could similarly rebind a declaration as the cast type.)<br>
>><br>
>> I think we'd have some weirdness. For instance:<br>
>><br>
>> ```<br>
>> guard x != nil || x == y else { break }<br>
>> // oops, now x isn't unwrapped anymore because I added a condition<br>
>> ```<br>
>><br>
>> Also, it'd be unexpected for it to be blessed for guard but not if:<br>
>><br>
>> ```<br>
>> if x != nil {<br>
>> // is x unwrapped here?<br>
>> // if so, this would be source-breaking...<br>
>> // if not, it would be surprisingly inconsistent<br>
>> }<br>
>> ```<br>
><br>
> `if` and `guard` share the same condition behavior. It's true that there would be limitations on when the unwrapping behavior applies, but QoI could potentially help. Users seem to be able to work within similar constraints in gradually-typed languages like Typescript that work similarly, and there's quite a lot of Swift users who are surprised at first that Swift doesn't behave similarly.<br>
><br>
> -Joe<br>
> ______________________________<wbr>_________________<br>
> swift-evolution mailing list<br>
> <a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a><br>
> <a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
______________________________<wbr>_________________<br>
swift-evolution mailing list<br>
<a href="javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');" target="_blank">swift-evolution@swift.org</a><br>
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank">https://lists.swift.org/mailma<wbr>n/listinfo/swift-evolution</a><br>
</div></div></blockquote></div><br></div>
</blockquote></div>