[swift-evolution] Enhanced existential types proposal discussion

[Austin Zheng]

I suppose "a.Element" could be considered a path-dependent type.

My inclination is to disallow the use of "a.AssociatedType" if 'a' is a
generic type like T inside func<T>(a: T) or class<T>, and only allow it if
'a' is an existential. This goes back to the notion that existential types
and generic types (universal types?) are two different concepts that are
closely related. Allowing the use of that notation would be an additive
change, so if necessary it could be expressed in a followup proposal (and
we could hash out all the semantics then).

Austin


On Thu, May 26, 2016 at 10:52 AM, Thorsten Seitz <tseitz42 at icloud.com>
wrote:

>
> Am 26.05.2016 um 07:53 schrieb Austin Zheng via swift-evolution <
> swift-evolution at 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.
>
>
> let a : Any<Collection>
>
> // A variable whose type is the Element associated type of the underlying// concrete type of 'a'.let theElement : a.Element = ...
>
>
> In Scala this would be a „path dependent type“ which actually depends on
> the variable `a`.
> What would happen in the following case:
>
> func foo<T: Any<Collection>>(a: T, b: T) {
> // is the type of a.Element equal to the type of b.Element here? (In Scala
> it would not)
> }
>
>
> -Thorsten
>
>
>
> 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
>
> Best,
> Austin
>
> On Tue, May 24, 2016 at 5:09 AM, Matthew Johnson via swift-evolution <
> 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> 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
>> > https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> 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/0d3f7d05/attachment.html>