> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution
> <[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>> { … }
I think what you’re looking for is an anonymous union type `A | B`, not an
existential made of the two of them.
To write this `union` and have it behave in the usual way you need `Any<A, B>`
to be a supertype of `A` and of `B`. The existential doesn’t actually do that
so it would not be possible for this union function to guarantee the result
would have all of the members of `x` and all the members of `y` the way that a
`union` usually would.
The anonymous union type `A | B` *is* a supertype of `A` and a supertype of `B`
so you would have no trouble writing this:
func union<A, B>(x: Set<A>, y: Set<B>) -> Set<A | B> { … }
And returning the expected result.
>
>
> -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
>
> _______________________________________________
> 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
