> On Oct 26, 2016, at 10:37 AM, Chris Lattner via swift-evolution
> <swift-evolution@swift.org> wrote:
>
> To me, this is the most promising direction, but I’d suggest the use of
> “unwrap" as the keyword. If you compare these two:
>
> a) guard let foobar = foobar else { … }
> b) guard unwrap foobar else { … }
>
> I think that b) wins by virtue of eliminating repetition ("foobar = foobar"
> fails DRY principles), but retains clarity by introducing a word into the
> grammar that people already commonly know and use, and which is googlable if
> they don’t.
>
> This also gives us the conceptual hook to make the “unwrapping an optional”
> behavior (which occurs with if let, optional chaining, etc) be something that
> could be extended to other similar user defined types, such as a Result type.
This might need a bit more fleshing out of the details. Given a result of T or
Error, I would expect the unwrap operation’s flow control to not be a
conditional but a throw - aka "try unwrap result” (or no need for a keyword -
try result.unwrap()). That is, unless I specifically request a projection.
For an async/await system based on promises, I would expect to use an “await”
keyword, not an “unwrap” keyword.
>
> -Chris
>
> _______________________________________________
> 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
