[swift-evolution] guard let x = x

Xiaodi Wu xiaodi.wu at gmail.com
Mon Oct 31 14:51:57 CDT 2016


An alternative that would seem to satisfy some objections is to have a
distinct "unwrap" statement--as in: "unwrap x else { ... }".
On Mon, Oct 31, 2016 at 14:49 Pyry Jahkola via swift-evolution <
swift-evolution at swift.org> wrote:

> Going back to the originating message of this thread. This idea (or a
> variant thereof) has been mentioned in the list of Commonly Rejected
> Proposals (2nd last bullet under Control Flow, Closures, Optional
> Binding, and Error Handling
> <https://github.com/apple/swift-evolution/blob/master/commonly_proposed.md#control-flow-closures-optional-binding-and-error-handling>
> ):
>
> Syntactic sugar for if let self-assignment
> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20160829/026796.html>:
> An alternative syntax (such as if let foo? { ... } or if let foo=? { ... })
> to serve as a shorthand for if let foo = foo { ... } is often proposed and
> rejected because it is favoring terseness over clarity by introducing new
> magic syntactic sugar.
>
>
> So any discussion on this topic would have to target these concerns first.
>
> On 26 Oct 2016, David Goodine wrote:
>
> 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:
>
> guard let x, y, z else {…}
>
>
> That said, while I don't mind having to repeat the variable name myself, I
> think David Goodine's syntax would have to repeat the `let` to align with
> SE-0099
> <https://github.com/apple/swift-evolution/blob/master/proposals/0099-conditionclauses.md>,
> like so:
>
>     *guard let* x, *let* y, *let* z *else* { ... }
>
> Personally, I wouldn't mind if this syntax existed. I think it explains
> itself rather well. And today, unlike when it was first discussed a long
> time before SE-0099, it's no longer confusable with Boolean conditions.
>
> But it's certainly out of scope for Swift 4 phase 1.
>
> — Pyry
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161031/e1cd2fab/attachment.html>


More information about the swift-evolution mailing list