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] <mailto:[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 >> >> <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
