[swift-evolution] guard let x = x

Xiaodi Wu xiaodi.wu at gmail.com
Mon Oct 31 17:02:50 CDT 2016


On Mon, Oct 31, 2016 at 4:44 PM, Erica Sadun <erica at ericasadun.com> wrote:

>
> > On Oct 31, 2016, at 1:51 PM, Xiaodi Wu via swift-evolution <
> swift-evolution at swift.org> wrote:
> >
> > An alternative that would seem to satisfy some objections is to have a
> distinct "unwrap" statement--as in: "unwrap x else { ... }".
>
> I'd be against this alternative as it is doing the work of a guard
> statement (including the "must exit scope" rule) with a new keyword and
> unneeded redundancy.
>
> Adding "unwrap" is local. It performs one very common task with added
> safety (avoids unintended shadow effects) and introduces succinctness and
> clarity. In other words, it is a highly focused changed with a measurable
> benefit in use.
>

Sure, I have no beef with `guard unwrap`. My point was that, if there's a
push for a more succinct statement, it must be `unwrap x` and not `guard x`
or `guard let x` for the same reasons we've discussed above.


> Compare:
>
> * "Introduce the unwrap statement that acts like guard but is limited to
> optionals" creates unnecessary language verbosity.
>
> * "guard x else ", meaning "treat optional values differently than all
> other items in a conditional list", fails because it obscures rather than
> adds intent. Worse, it would lead to issues with Boolean optionals whose
> wrapped value is later used within the same condition.
>
> Xiaodi, you mentioned an alternative approach and I'd love a peek at what
> that is.
>

Not for unwrapping; for enums. I'll write you offlist :)


> -- Erica
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20161031/21a6865e/attachment.html>


More information about the swift-evolution mailing list