> On Jan 4, 2016, at 12:40 PM, Douglas Gregor <dgre...@apple.com> wrote: > >> >> On Jan 4, 2016, at 10:30 AM, Matthew Johnson <matt...@anandabits.com >> <mailto:matt...@anandabits.com>> wrote: >> >>> >>> On Jan 4, 2016, at 12:21 PM, Douglas Gregor via swift-evolution >>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>> >>> >>>> On Jan 3, 2016, at 4:19 PM, David Waite <da...@alkaline-solutions.com >>>> <mailto:da...@alkaline-solutions.com>> 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. > > We are, and lots of them. I doubt we can handle another. > >> 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>? > > I was thinking mostly about the former. However, the latter is also a > highly-requested feature [*] that complements this one, and I think it’s > reasonable to discuss both together. > > - Doug > > [*] And is often the underlying reason why developers ask for parameterized > protocols.
Agree. The other primary motivation I know of for that request is something like ConvertibleTo<T> where you multiple conformances would be possible. I am familiar with the reasons why Swift is avoiding that path. :) > > >> >>> >>> - Doug >>> >>>> >>>> -DW >>>> >>>>> On Jan 3, 2016, at 4:17 PM, Douglas Gregor via swift-evolution >>>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>>> >>>>> >>>>>> On Jan 3, 2016, at 6:48 AM, Антон Жилин via swift-evolution >>>>>> <swift-evolution@swift.org <mailto:swift-evolution@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 >>>>>> >>>>>> <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@swift.org <mailto:swift-evolution@swift.org> >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
