+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 < [email protected]> 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 < > [email protected]> wrote: > > > On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution < > [email protected]> 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
