> Am 28.05.2016 um 22:04 schrieb Matthew Johnson <[email protected]>: > > >> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution >> <[email protected] <mailto:[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>())`?
(I meant `intersection` instead of `union`… see my other response, but for the union case which should result in `Set<A | B>` I would expect Set<Int | String>; for the intersection case I would expect Set<Any<Int, String>> which would be Set<Bottom> or Set<Nothing> in Ceylon, where the bottom type is called `Nothing`). -Thorsten > >> >> >> -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 >>> <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
