[swift-evolution] guard let x = x

[Thorsten Seitz]

> Am 01.11.2016 um 19:42 schrieb Erica Sadun via swift-evolution <swift-evolution at swift.org>:
> 
> Here are a few varieties of how that call might look versus the proposed update for normal pattern matching:
> 
> if unwrap .string(myString) ~= json { ... }
> if unwrap .contact(code, _) ~= response { ... }
> if unwrap .contact(code, var message) ~= response { ... }
> 
> // vs proposed
> 
> if let .string(myString) ~= json { ... }
> if var .string(myString) ~= json { ... }
> if .contact(let code, _) ~= response { ... }
> if .contact(let code, var message) ~= response { ... }
> Although slightly wordier than let and var, the unwrap solution offers advantages:
> 
> It enhances readability. If the goal is to unwrap an embedded value, unwrap uses a more appropriate term.
> It establishes one place for the keyword to live instead of the "does it go inside or outside" status quo. A consistent place means prettier code.
The `unwrap` variant loses the ability to distinguish between binding a variable (which means the variable will be preceded by `let`) and matching against the value of a variable, e.g. the following are very different:

let code = 1
if case .contact(code, let msg) = response {...}

vs.

if case .contact(let code, let msg) = response {...}

Actually for that proposed use of `unwrap` I see no advantage over the existing `case` which I prefer over the ~= operator. The assignment operator does not look wrong in my eyes, either, because it is quite natural to have bindings happen on the left side of it.

Using `unwrap` solely as replacement for `let x = x`, i.e. as `unwrap x` is fine with me.

-Thorsten 


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161102/ce70b5d3/attachment.html>