[swift-evolution] The bind thread

[T.J. Usiyan]

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/e42e0e42/attachment.html>