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?
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.
Best,
Taras
> On 26 May 2016, at 07:53, Austin Zheng via swift-evolution
> <[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]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
