In Rust lang, it uses .unwrap and b can be a non-nil variable. guard a.unwrap, b, c.unwrap else { }
On Tuesday, November 1, 2016, Nicholas Maccharoli via swift-evolution < swift-evolution@swift.org> wrote: > I like the idea of drying up something like `guard let x = x, let y = y, > let z = z else { return }` > Using `guard unwrap` would surely be an improvement but still maybe > something like `guard unwrap x, unwrap y, unwrap x else { return }` > although very clear in intent is a bit bulky. > > 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. > > one way might be: > > guard given a, b, c else { return } > > or with an attached conditional: > > guard given a, b, c where a > b else { return } > > for dealing with long if-lets you could do something like: > > if given a, b, c where a > b { ... } > > Instead of if let a = a, b = b, c = c, a > b { ... } > > The `where` clause does not need to be an actual keyword, it can just be a > trailing boolean expression but > maybe having it makes things like unwrapping and testing that a variable > evaluates to `true` more distinguishable. > > 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 { ... }` > > `if given a, b, c where c { ... }` might read a little easier. > > Just a thought. > > - Nick > > > > > > On Tue, Nov 1, 2016 at 4:26 PM, Goffredo Marocchi via swift-evolution < > swift-evolution@swift.org > <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: > >> Agreed, a change like this would make sense :). >> >> Sent from my iPhone >> >> > On 1 Nov 2016, at 01:58, Joe Groff via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: >> > >> > >> >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <xiaodi...@gmail.com >> <javascript:_e(%7B%7D,'cvml','xiaodi...@gmail.com');>> wrote: >> >> >> >> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution < >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');>> wrote: >> >> 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.) >> >> >> >> I think we'd have some weirdness. For instance: >> >> >> >> ``` >> >> guard x != nil || x == y else { break } >> >> // oops, now x isn't unwrapped anymore because I added a condition >> >> ``` >> >> >> >> Also, it'd be unexpected for it to be blessed for guard but not if: >> >> >> >> ``` >> >> if x != nil { >> >> // is x unwrapped here? >> >> // if so, this would be source-breaking... >> >> // if not, it would be surprisingly inconsistent >> >> } >> >> ``` >> > >> > `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. >> > >> > -Joe >> > _______________________________________________ >> > swift-evolution mailing list >> > swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >> > https://lists.swift.org/mailman/listinfo/swift-evolution >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> <javascript:_e(%7B%7D,'cvml','swift-evolution@swift.org');> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> > >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution