> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution > <[email protected]> wrote: > > I’m not happy with that restriction in the proposal: > > Existentials cannot be used with generics in the following ways: > > In generic declarations, with the requirements composed out of generic type > variables: > > // NOT ALLOWED > func foo<A, B>(x: A, y: B) -> Any<A, B> { ... } > > Why is that not allowed? > > I would have hoped to be able to write something like > > func union<A, B>(x: Set<A>, y: Set<B>) -> Set<Any<A, B>> { … }
What do you expect to happen when someone writes: `union(Set<Int>(), Set<String>())`? > > > -Thorsten > > > >> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution >> <[email protected] <mailto:[email protected]>>: >> >> 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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
