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>> { … }
-Thorsten
> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution
> <swift-evolution@swift.org>:
>
> 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
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>
>
> Sent from my iPad
>
> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution
> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> 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
> > 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
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
