[swift-evolution] The bind thread

[Jacob Bandes-Storch]

I think it's also worth mentioning Ceylon's flow-sensitive typing
<http://ceylon-lang.org/documentation/1.2/introduction/#typesafe_null_and_flow_sensitive_typing>
features, pointed out by Thorsten Seitz:

This is called flow typing in Ceylon and they are using "exists" for that
> case but testing for conformance with "is" works just the same way there.
> The latter is of importance because the common use of union types in Ceylon.
> if exists foo {
>         // foo is non-optional here
> }
> if foo is String {
>         // foo is of type String here
> }


Seems like a neat option to me.

On Mon, 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/ef0829de/attachment.html>