[swift-evolution] Enhanced existential types proposal discussion
xenadu at gmail.com
Thu Jun 30 13:49:09 CDT 2016
> On May 17, 2016, at 11:52 AM, Austin Zheng via swift-evolution <swift-evolution at swift.org> wrote:
> I put together the skeleton of a proposal detailing enhancements to how associated types can be referenced in Swift 3+. It's certainly not ready for submission, but I think it gets across my ideas pretty well. Would love to gather feedback and especially improvements.
Austin, these comments are on the updated proposal (86d209e).
> In such a case, it is not allowed to define constraints that create a relation between different existential values:
> // NOT ALLOWED; each constraint can reference at most a single existential
> // value (argument or return value)
> func doSomething(x: Collection, y: Collection)
> where x.Element == y.Element
> // ...
What is the rationale for this restriction? I’m not arguing against it, but I’d like to understand it better… maybe the proposal should include a small explanation?
> Unconditional casting to covariant generic output types (i.e. Optional<T>) is allowed, even without concrete type constraints.
Maybe it’s just me but this might warrant a little bit of explanation. Swift doesn’t have a mechanism for specifying covariant/contravariant type parameters so I assume that’s just inferred if SomeType<AssociatedType> appears in output position anywhere in the protocol? I also assume you must constrain all the type parameters of the generic type to use it this way.
> Existentials cannot be used with generics in the following ways:
> Passed as arguments of generic type T to generic functions, unless T is completely unconstrained and the argument's type is T or a generic type covariant on T.
I’m not quite parsing this one. If the existential is constrained enough to satisfy the function’s generic constraints why can’t the compiler call the non-specialized version? (I’m probably just misunderstanding)
> A type A is a subtype of another type B iff B can be used anywhere A can without changing the semantics of the program.
Is this correct? It might be my confusion but it seems like "A type A is a subtype of B iff A can be used anywhere B can without changing the semantics of the program”. That seems to fit with the example of “String is a subtype of Streamable” because “String can be used anywhere Streamable can”.
Thanks to everyone for their work on this proposal, it looks fantastic!
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution