[swift-evolution] The bind thread

[T.J. Usiyan]

My apologies for the double post but 2.2 (no need for backticks around
'else' as a parameter name) allows a slightly different approach right now
(I am not exactly suggesting that this solves the problem completely, just
seeing what it looks like.)

        func unwrap<Wrapped>(wrapped: Wrapped?, _ unwrapHandler: Wrapped ->
Void, else failureHandler: Void -> Void) {
   switch wrapped {
   case let .Some(value):
       unwrapHandler(value)
   case .None:
       failureHandler()
   }
}

// allows

let theBox:Int? = 4

unwrap(theBox, { print("the value is \($0)") }
   , else: {
   print ("Nothing in the box!")
})


On Mon, Feb 1, 2016 at 3:14 PM, T.J. Usiyan <griotspeak at gmail.com> wrote:

> Ok, would that mean that we could use closure syntax to …associate the
> value with a name?
>
>   if bind foo.somethingReturningAnOptional { foo in
>       // ???
>   }
>
> I think that the question brings me back to my initial thought when
> reading this that it is dangerously "close but not quite the same as" the
> 'other' meaning of `bind`. I don't thank that the closeness should shut
> down discussion of this but I would like to float the name `unwrap`
> instead. This makes a near-implementation that is currently possible make
> more sense.
>
> func unwrap<Wrapped>(wrapped: Wrapped?, handler: Wrapped -> Void) -> Bool
>
>
> The `Bool` represents whether or not the unwrap was successful and the
> `else` flows from that thought without issue. (`bind` works in this regard
> as well but becomes, in my opinion, it becomes even more confusing to have
> a bind with the suggested signature.)
>
> TJ
>
>
> On Mon, Feb 1, 2016 at 2:27 PM, Erica Sadun <erica at ericasadun.com> wrote:
>
>> It would have to be something along the lines of $0 wouldn't it? If there
>> was no clear single symbol to shadow?
>>
>> That's a very good point, and thank you for bringing it up.
>>
>> -- Erica
>>
>> On Feb 1, 2016, at 12:22 PM, T.J. Usiyan <griotspeak at gmail.com> 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
>>>
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160201/db870f6f/attachment.html>