[swift-evolution] The bind thread

[Andrew Bennett]

I'm -1 as stated, I don't think the proposed change adds any clarity, if
anything it adds more things to learn.

I think you can achieve some of your goals with a linter. You need to
consider how this works with pattern matching. It would remove the ability
to mutate the value type in a switch without a reassignment.

I'm closer to liking it if it removes nothing from the language and adds
something like this:

var x: Int?
let y: Int?
if bind x, y where x == y {
    x = 4 // changes the x outside this scope
    y = 5 // compile time error
    x = nil // compile time error
}

I think that makes bind make more sense, and less surprising. However it
doesn't clarify anything about it no longer being optional.

It would be nice if the following worked, although I it has its own issues
with surprises:

let x: Int? = 123
if x != nil {
   ... // x is non-optional here
}
assert(x != nil)
// x is non-optional here

var y: Int? = 456
while y != nil {
    // y is non-optional here
}
// y is optional here

On Tuesday, 2 February 2016, T.J. Usiyan via swift-evolution <
swift-evolution at swift.org> wrote:

> I don't think that the keyword is silly but this is a good point. I forgot
> that this application of the `?` postfix exists.
>
> On Mon, Feb 1, 2016 at 2:56 PM, Tyler Cloutier via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>> 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> 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> 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> 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
>>>>
>>>>
>>> _______________________________________________
>>> swift-evolution mailing list
>>> swift-evolution at swift.org
>>> 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
>>
>>
>>
>> _______________________________________________
>> 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/77174fb9/attachment-0001.html>