[swift-evolution] [Manifesto] Completing Generics

[Developer]

Anti-modular as in it requires intimate knowledge of the underlying types and isn't trivially extensible.  For example, the GADT thing was essentially a sealed hierarchy where each instance of the common protocol declared a constructor and parameters.  Methods dispatched by casting as here.  Difference is, Swift was able to, rightly, complain about certain twisty casts, especially generic ones, being invalid under that scheme.  I'm worried this will introduce a new type variable and allow the user to arbitrarily "bind" it by special casing like that.  Unless I'm misunderstanding something about the original example.

~Robert Widmann

2016/03/02 23:22、Joe Groff <jgroff at apple.com> のメッセージ:

> 
>>> 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/24c9723d/attachment.html>