> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution > <[email protected]> wrote: > > >> On Jan 3, 2016, at 4:19 PM, David Waite <[email protected] >> <mailto:[email protected]>> wrote: >> >> This would be wonderful - is it something that could happen in the Swift 3 >> timeframe? > > I hesitate to say “yes” here. I think it fits with the goals of Swift 3, but > my main concern is that there isn’t enough engineering bandwidth to implement > it for Swift 3. > >> Is it something that myself or someone else could work on a formal proposal >> for? > > Yes, absolutely. This is a case where I think it’s useful to design what we > want, even if we cannot fit the implementation into the Swift 3 schedule. > It’s also a case where the compiler has a lot of the pieces already > implemented (with some runtime bits landing soon), so the implementation > should not be *that* hard and will likely not require architectural changes.
Interesting. I was under the impression the core team was taking on the generics features. I am also very interested in helping to accelerate the process if that is possible (whether that means Swift 3 or not). Are you thinking specifically about unbound existentials like in your Equatable example or also partly / fully bound existentials such as SequenceType<Generator.Element == Int>? > > - Doug > >> >> -DW >> >>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution >>> <[email protected] <mailto:[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] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <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
