[swift-evolution] The bind thread

[David Waite]

Meta-comments:

"if let y = x { … } “ actually corresponds closest to

if x != nil {
   let y = x!
   …
}

e.g. has the following behaviors:
1. a comparison to nil
2. a copy of the reference or value w/o optionality
3. execution of a block

but also:
4. implication that this is safe within the block (my eyes would be drawn to that "let y = x!” every time)
5. ability to shadow outer optional variable with non-optional inner variable (e.g. if let x = x { … } )

You could do all of this of course via .flatMap, but there is an obvious desire for something closer to the traditional/familiar syntax of a conditional. 

Having a special case of variable assignment within a conditional that casts off optionality feels odd, and I can understand why people have proposed changes. However, the proposals so far seem to have gotten hung up around point #2, having issues with either:

a) making it less clear that a copy is being made,
b) making it less clear that a copy is shadowing the original value, and/or
c) changing the capabilities of the actual statement, such that a copy is *not* being made, and the original value is effectively inout. This means that you are not actually replacing all uses of the syntax at all, but instead defining a new kind of operation.

Issues with a) and b) are syntactic. We can possibly come up with a more clear way to explain the current behavior, although its very hard to make it more clear that a copy is being made than a ‘let’ declaration and assignment. 

Issues with c) are mostly just around clarity of purpose - you are defining something new, and "if let x = x” will likely still exist because uses for that operation are still likely valid.

-DW

> On Feb 1, 2016, at 12: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.
> 
> 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/81fcca60/attachment.html>