[swift-evolution] [Manifesto] Completing Generics

[Joe Groff]

> On Mar 2, 2016, at 7:57 PM, Developer via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> Existentials
>> 
>> Opening existentials
>> 
>> Generalized existentials as described above will still have trouble with protocol requirements that involve Self or associated types in function parameters. For example, let’s try to use Equatable as an existential:
>> 
>> protocol Equatable {
>>   func ==(lhs: Self, rhs: Self) -> Bool
>>   func !=(lhs: Self, rhs: Self) -> Bool
>> }
>> 
>> let e1: Equatable = …
>> let e2: Equatable = …
>> if e1 == e2 { … } // error: e1 and e2 don’t necessarily have the same dynamic type
>> 
>> One explicit way to allow such operations in a type-safe manner is to introduce an “open existential” operation of some sort, which extracts and gives a name to the dynamic type stored inside an existential. For example:
>> 
>> 	 
>> if let storedInE1 = e1 openas T {     // T is a the type of storedInE1, a copy of the value stored in e1
>>   if let storedInE2 = e2 as? T {      // is e2 also a T?
>>     if storedInE1 == storedInE2 { … } // okay: storedInT1 and storedInE2 are both of type T, which we know is Equatable
>>   }
>> }
> 
> Isn't "open existential" code for "casting ∃ to ∀"? Dispatch on the underlying type is brittle and anti-modular.

I'm not sure exactly what you're referring to, but our existential type representation captures the type and protocol conformance metadata that was statically available when the existential value was constructed, so I don't think there's a modularity problem. This operation would rebind that metadata to a type conforming to the protocol in the scope where the type binding is introduced.

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160302/7e8744e3/attachment.html>