> On May 17, 2016, at 11:52 AM, Austin Zheng via swift-evolution
> <[email protected]> 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 _______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
