> Am 28.05.2016 um 22:08 schrieb Matthew Johnson <[email protected]>:
>
>
>> On May 28, 2016, at 2:31 PM, Thorsten Seitz via swift-evolution
>> <[email protected] <mailto:[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.
Sorry, I of course meant
func intersection<A, B>(x: Set<A>, y: Set<B>) -> Set<Any<A, B>> { … }
I guess I will forever confuse this until we write existentials with `&`…
You are right, for the union I want the union type `A | B`. But that is stuff
for another proposal.
-Thorsten
>
> 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
>>> <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
