[swift-evolution] [Proposal] Separate protocols and interfaces

[Austin Zheng]

+1 to "opening" values of existential type, I remember trying (and failing)
to do this when Swift 1 came out. Being able to capture the dynamic type of
an object at runtime and do stuff with it would be incredible.

Austin

On Sun, Jan 3, 2016 at 4:19 PM, David Waite via swift-evolution <
swift-evolution at swift.org> wrote:

> This would be wonderful - is it something that could happen in the Swift 3
> timeframe? Is it something that myself or someone else could work on a
> formal proposal for?
>
> -DW
>
> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution <
> swift-evolution at swift.org> wrote:
>
>
> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> Introduction of interfaces will clean up the current blend of static and
> dynamic protocols, and solve at least three popular issues.
> Please see:
>
> https://github.com/Anton3/swift-evolution/blob/master/proposals/0000-introducing-interfaces.md
>
>
> I am *completely* against this proposal.
>
> Fundamentally, you're trying to address the limitation that protocols with
> Self or associated type requirements can't be existential. But it's just a
> limitation that isn't (conceptually) that hard to fix: the primary
> operation you need to work with an existing of such a protocol is to "open"
> a value of existential type, giving a name to the dynamic type it stores.
> Let's invent one:
>
>   func eq(x: Equatable, y: Equatable) -> Bool {
>     // give the name T to the dynamic type stored in xT
>     let xT = open x as T
>     // is y also storing a T?
>     guard let yT = y as? T else { return false }
>     // check whether the Ts are equal
>     return xT == yT
>   }
>
> Ignore the syntax: semantically, we've gone from a "dynamic" existential
> thing back to something more "static", just by giving a name to the type.
> Swift generics aren't really even static in any sense: what the do is give
> names to the types of values so one can establish relationships among
> different values. "open..as" would do that for existentials.
>
> Note that ether Swift compilers AST and SIL both have "open existential"
> operations that do this internally. They have no spelling in Swift code,
> but they are useful to describe operations on existentials. At present,
> they cannot be formed when the existential involves a protocol with Self or
> associated type requirements, but that's a limitation that isn't hard to
> address.
>
> As for your concerns about knowing when one can dynamically override and
> when one cannot...  There are issues here that need to be addressed. They
> aren't significant enough to warrant such a drastic change, and may not
> even require language changes at all.
>
> - Doug
>
>
> _______________________________________________
> 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/20160103/33e7889f/attachment.html>