[swift-evolution] The bind thread

[Tyler Cloutier]

The bind or exists keywords seem sort of silly to me. There is already syntax for binding optionals:

if x? {
	foo(x) // x type narrowed after binding.
}

Tyler


> On Feb 1, 2016, at 11:35 AM, Howard Lovatt via swift-evolution <swift-evolution at swift.org> wrote:
> 
> I like this proposal. I also think that either bind or exists could be the keyword. I would suggest that both forms of syntax should be allowed, e.g.:
> 
>     if bind x { /* x is non-nil, unwrapped, and hides original x inside if statement */ }
>     if bind x = object.property { /* x is non-nil and unwrapped */ }
> 
> On Tuesday, 2 February 2016, Dave via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
> I think it’d be _
> 
> You could use it to test if the return value is non-nil, but you’d have to revert to “if let x = …” to actually use the results.
> 
> I think.
> 
> - Dave Sweeris
> 
>> On Feb 1, 2016, at 11:22, T.J. Usiyan via swift-evolution <swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>> wrote:
>> 
>> This is interesting. What name is created by 
>> 
>>   if bind foo.somethingReturningAnOptional {
>>       // ???
>>   }
>> 
>> On Mon, Feb 1, 2016 at 2:18 PM, Erica Sadun via swift-evolution <swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','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 <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <javascript:_e(%7B%7D,'cvml','swift-evolution at swift.org');>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 
> 
> -- 
>   -- Howard.
> 
> _______________________________________________
> 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/bdc4d392/attachment.html>