Thank you for your comments! (inline) > On May 26, 2016, at 4:59 AM, Taras Zakharko <[email protected]> wrote: > > This looks very nice! > > Two questions/comments > > 1. I would prefer to write simpler existential types without Any, e.g.: > > let a: Sequence where Sequence.Iterator.Element == Int > > Is there a reason why we need Any<> at all, aside as a parsing aid? >
Not really. All the syntax in that pre-proposal is contingent on whatever happens to #95 (https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md <https://github.com/apple/swift-evolution/blob/master/proposals/0095-any-as-existential.md>), which is currently under review. > 2. If this proposal gets accepted, does it mean that type-erased wrappers > like AnySequence become superfluous? They always struck me as a hack, used > only to overcome the limitations of the type system. Probably. I could see type aliases being defined for AnySequence and the three types of Collections. > > Best, > > Taras > > > >> On 26 May 2016, at 07:53, Austin Zheng via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> The inimitable Joe Groff provided me with an outline as to how the design >> could be improved. I've taken the liberty of rewriting parts of the proposal >> to account for his advice. >> >> It turns out the runtime type system is considerably more powerful than I >> expected. The previous concept in which protocols with associated types' >> APIs were vended out selectively and using existentials has been discarded. >> >> Instead, all the associated types that belong to an existential are >> accessible as 'anonymous' types within the scope of the existential. These >> anonymous types are not existentials - they are an anonymous representation >> of whatever concrete type is satisfying the existential's value's underlying >> type's associated type. >> >> This is an enormous step up in power - for example, an existential can >> return a value of one of these anonymous associated types from one function >> and pass it into another function that takes the same type, maintaining >> perfect type safety but without ever revealing the actual type. There is no >> need anymore to limit the APIs exposed to the user, although there may still >> exist APIs that are semantically useless without additional type information. >> >> A set of conversions has also been defined. At compile-time 'as' can be used >> to turn values of these anonymous associated types back into existentials >> based on the constraints defined earlier. 'as?' can also be used for >> conditional casting of these anonymously-typed values into potential actual >> types. >> >> As always, the link is here, and feedback would be greatly appreciated: >> https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md >> >> <https://github.com/austinzheng/swift-evolution/blob/az-existentials/proposals/XXXX-enhanced-existentials.md> >> >> Best, >> Austin >> >> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> Sent from my iPad >> >> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> >> One initial bit of feedback - I believe if you have existential types, I >> >> believe you can define Sequence Element directly, rather than with a type >> >> alias. e.g. >> >> >> >> protocol Sequence { >> >> associatedtype Element >> >> associatedtype Iterator: any<IteratorProtocol where >> >> IteratorProtocol.Element==Element> >> >> associatedtype SubSequence: any<Sequence where Sequence.Element == >> >> Element> >> >> … >> >> } >> > >> > That's not really the same thing. Any<IteratorProtocol> is an existential, >> > not a protocol. It's basically an automatically-generated version of our >> > current `AnyIterator<T>` type (though with some additional flexibility). >> > It can't appear on the right side of a `:`, any more than AnyIterator >> > could. >> >> After this proposal you should be able to use these existentials anywhere >> you can place a constraint, so it would work. You can do this with the >> protocol composition operator today and the future existential is just an >> extension of that capability. >> >> > >> > What *would* work is allowing `where` clauses on associated types: >> > >> >> protocol Sequence { >> >> associatedtype Element >> >> associatedtype Iterator: IteratorProtocol where Iterator.Element==Element >> >> associatedtype SubSequence: Sequence where SubSequence.Element == Element >> >> … >> >> } >> > >> > I believe this is part of the generics manifesto. >> > >> > -- >> > Brent Royal-Gordon >> > Architechies >> > >> > _______________________________________________ >> > 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] <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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
