[swift-evolution] guard let x = x

[Nevin Brackett-Rozinsky]

I think I agree with Tino, the use-case of “unwrap” for shadowing is not
compelling enough to justify adding a keyword.

Moreover, regarding the generalized enum associated-value extraction
situation, the approach I described earlier is copacetic to both
destructuring tuples and leaving them intact. For example, with this enum
from Erica’s revised proposal:

enum Response {
    case contact(code: Int, message: String)
    case failure
}

We can extend it like so:

extension Response {
    var contact: (code: Int, message: String)? {
        if case let .contact(x) = self { return x }
        return nil
    }
}

And then access its associated values either as a tuple or as separate
variables:

let r = Response.contact(code: 6, message: "Seven")

if let t = r.contact {
    print(t.code, t.message)
}

if let (c, m) = r.contact {
    print(c, m)
}

To make this work without manually implementing the boilerplate extension,
I propose either a magic “Unwrappable” protocol which when conformed to by
an enum will automatically generate the equivalent of that boilerplate, or
else an “@unwrappable” attribute that can be applied to individual enum
cases (and perhaps to an enum declaration if every case with an associated
value should have it).

Furthermore, in the special case of an enum with only one unwrappable case,
we could add sugar to make it “act like” an Optional for conditional
binding, meaning eg. “.contact” could be elided and it would be usable as:

if let x = r { … }

I think this makes for better code and a simpler language than the proposed
alternatives involving an “unwrap” keyword, and it does not involve any
source-breaking changes. It also lifts conditional-binding from a niche
Optional-only feature, to a user-accessible tool for enums broadly.

Nevin


On Wed, Nov 2, 2016 at 12:53 PM, Tino Heth via swift-evolution <
swift-evolution at swift.org> wrote:

> Imho it would be better not to add "uwrap".
> Yes, it might be nicer in some situations, but it is also nice to have a
> simple (or at least less complicated) language.
> For me, the actual benefit is to low to justify a separate keyword which
> creates questions that don't exist with the current syntax.
> It is quite clear that "if let" declares a new value, whereas "unwrap"
> introduces ambiguity.
>
> Have a look at this line:
> if unwrap someObject.someFunction() { print("?") }
> Should the compiler accept it?
> If yes: Should it be possible to access the return value of someFunction?
> How?
> If no: What about "someObject.someComputedProperty"? What if you exchange
> "someObject" with "self"?
>
> What if I want to modify an unwrapped value? "if var" is quite intuitive,
> but unwrap… maybe it depends on the original value, or is there a second
> variant?
>
> There might be good answers for all those questions, but they aren't
> obvious.
>
> _______________________________________________
> 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/20161102/8f2ba6d5/attachment.html>