[swift-evolution] The bind thread

[David Owens II]

I disagree. The “if let” and “if var” are part of the pattern matching syntax that is fairly unified throughout the language, especially with the reversal for removing “if var” from Swift. Also, does “bind” also replace the “let” and “var” usage in case statements? And how do you handle this case?

let items: [Int]? = [1, 5, 4]

if var items = items {
    items.sortInPlace()
}



-David


> On Feb 1, 2016, at 11:18 AM, 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/9facd466/attachment.html>