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> 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> wrote: > > > > > >> On Oct 31, 2016, at 6:46 PM, Xiaodi Wu <xiaodi...@gmail.com> wrote: > >> > >> On Mon, Oct 31, 2016 at 8:37 PM, Joe Groff via swift-evolution < > 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 > > https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > 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