[swift-evolution] Enhanced existential types proposal discussion

[Russ Bishop]

> 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!

Russ 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160630/8b8f5af6/attachment.html>