[swift-evolution] Enhanced existential types proposal discussion

Austin Zheng austinzheng at gmail.com
Thu May 26 10:28:53 CDT 2016


> On May 26, 2016, at 6:02 AM, Matthew Johnson <matthew at anandabits.com> wrote:
> 
> 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).

Yes, this is exactly what I meant. I'll make the copy clearer. Thanks!

> 
>> 
>> Best,
>> Austin
>> 
>> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> 
>> Sent from my iPad
>> 
>> On May 23, 2016, at 9:52 PM, Brent Royal-Gordon via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
>> > https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160526/f35238a4/attachment.html>


More information about the swift-evolution mailing list