Sent from my iPad
> On May 26, 2016, at 12:53 AM, Austin Zheng <[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 I really like the enhancement. This makes a lot of sense. All members are visible, but some members can't be called because you can't form an argument of the necessary type (i.e. when it is a non-concrete associated type and you can't get a value as output of another member of the existential). Thanks for chiming in on this Joe! There is one part of the update that could use clarification: // Okay, because String conforms to both Protocol1 and Streamable let r2 = result as? String I think you mean that the attempted cast is ok because there is a possibility it might succeed, but it might also fail. The possibility of failure should probably be highlighted. You might also want to elaborate that the Int attempt is a compiler error because there is no possibility for the attempted cast to succeed (if that is what you intend). > > Best, > Austin > >> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution >> <[email protected]> wrote: >> >> >> Sent from my iPad >> >> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution >> <[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] >> > 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
