[swift-evolution] The bind thread

[ilya]

I respectfully disagree with the need for bind operator, see below:

On Mon, Feb 1, 2016 at 8:18 PM, Erica Sadun via swift-evolution <
swift-evolution at swift.org> 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.
>

let A = B does exactly the same in all instances: evaluate the expression B
in current scope and bind the result to a local name A, and if let x =
x meaning
is no different. If a person doesn't know the precise meaning of if let,
with the similarity to normal let one is likely to guess at least the "name
binding" part. This is a big advantage of if let syntax.


> 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
>   }
>
>
Let's consider the case where foo was originally a property. Unfortunately,
the syntax above is then very likely to confuse people into thinking that
self.foo is non-optional inside the inner scope, which is far from
guaranteed:

if bind foo {
    // we have created a local variable foo here
    // foo is non-optional
    // no guarantees about self.foo can be made, however
    // as it's value may have changed
}

The same applies if foo is a local variable captured by an escaped closure
which may be executing concurrently with the inner block.

So it seems like the bind statement is most helpful only when foo is a
local name and either declared with let or not captured by any escaped
closure. In that case the original foo can be used directly without
shadowing.

One sees how such a statement can be useful, but I'm not sure if the word
bind is the best one for it. After all, both let and var perform name
binding. Also, there were suggestions to make

// foo is local and not escaping
if foo != nil {
    // foo is non-optional
}

simply work without any additional syntax. Perhaps one can look into that.

  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.
>
>
The 'big picture argument'  is that shadowing is likely to introduce more
errors, so we should be discouraging it, not encouraging. In real life I
find creating a local variable with a different name more natural anyway,
e.g:

// issuesViewController is a property
// we want to present it, if it can be constructed

if let to_present = issuesViewController {
    presentViewController(to_present, animated: true)
}

Ilya.

-- 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/20160202/c2a0e38d/attachment.html>