[swift-evolution] The bind thread

[Erica Sadun]

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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/599417bc/attachment.html>