[swift-evolution] The bind thread

[Kevin Ballard]

We've had multiple threads in the past suggesting many different
variants on

if let foo {    // foo is non-optional in here }

The only difference with this one is it uses the keyword "bind" instead
of any of the various similar alternatives in the other threads.

And my answer is the same to all of this: This is a bad idea. Your
construct here does not actually include any notion of assignment or
initialization. The construct `if bind foo { ... }` looks like nonsense
to anyone who doesn't already explicitly know that it's shorthand for
`if let foo = foo { ... }`.

If your goal here is to just avoid having to write the `= foo`, then I
disagree with the whole motive. If your goal here is to just use a
keyword `bind` instead of `let` (e.g. if you want to use `if bind foo =
foo { ... }`), I still disagree, because this new keyword serves no
purpose. `if let foo = bar { ... }` is not "fundamentally different"
than `let foo = bar`, it's still binding a new identifier to a value,
the only difference is it binds it to an optional value. And it's
really just a specialization of `if case let foo? = bar { ... }`. I've
asked in the past about whether it's worth keeping the special case
around now that we have `if case let` (or more specifically, if we
should just turn `if let` into the generalized version, so you'd say
`if let foo? = bar {... }`) and the answer from the core team was that
they already tried it internally and found that the usage of optionals
was so prevalent that the special-case optional-specific form of `if
let` was worth keeping.

-Kevin Ballard

On Mon, Feb 1, 2016, at 11:18 AM, Erica Sadun via swift-evolution wrote:
> Joe says "If you all are serious about this, I think you should start
> a new thread about it." I think it's worth a serious discussion just
> so it can be evaluated and either adopted or discarded and dropped
> forever. Here goes.
>
> INTRO
>
> The if let x = x {...} and guard let x = x else {...} constructs do
> something with let (and var) that's fundamentally different from let
> (and var) elsewhere in the language.  The same keywords are used to
> conditionally unwrap and bind an item, not just shadow that item's
> current value.
>
> Introducing a new bind keyword to indicate unwrapping and binding
> would disambiguate these uses.
>
> DETAIL DESIGN:
>
> Jacob Bandes-Storch offers two common use-cases. I prefer his "if bind
> foo" to my original "if bind foo = foo":
>
> if bind foo {      // foo is non-optional in here  }
>
> somethingAsync { [weak self] in      guard bind self else { return }
> // ...  }
>
> JBS's approach offers my original "bind" keyword to unwrap and shadow
> bind, but also provides a way to strongly bind a weak reference to
> self, which (presumably) would allow self semantics in the remaining
> lifetime of that scope.
>
> ALTERNATIVE PROPOSALS:
>
> Tino Heth proposes a second use-case one with different semantics.
> This case, it seems to make an alias rather than using binding for
> shadowing:
>
> bind x = a.property.with.a.long.path print x  // 42
> print(a.property.with.a.long.path == 42) => true
>
> presumably this means:
>
> x += 1 print(a.property.with.a.long.path)  // 43
>
> DISCUSSION
>
> I'm throwing these both out there. I have nothing to really say about
> Tino's but I do think my and Jacob's proposal has the advantages of:
>
> * Simplifying an mildly complex and potentially misleading statement
> * Creating a deliberate and controlled rather than accidental
>   shadowing style
>
> Have at it.
>
> -- Erica
>
>
> _________________________________________________
> 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/20160201/0643430e/attachment.html>