[swift-evolution] Make generics covariant and add generics to protocols

Howard Lovatt howard.lovatt at gmail.com
Tue Jan 12 22:02:52 CST 2016

I should be clear, I am not proposing the Java way. I haven't seen a
language that uses the system I am proposing where the instance carries a
field that says what type it accepts and that is checked at runtime. From
using this pattern in my own code it seems to work better than either the
current associated types and also the Haskel/Java/Scala type erasure

However since it is only tested in the sort of code I write it could be
that I haven't turned up all the problems. Do you have a *short* example of
where a Java system failed so that I can see how it would go using this

Hope you can find a suitable example,

 -- Howard.

On 13 January 2016 at 13:07, David Waite <david at alkaline-solutions.com>

> Java only has invariance at the generic type definition level. They allow
> you to use wildcards as another option to generic constraints for instance
> references. In effect, variance is faked by the user of a type, not defined
> by the author of the type.
> The dynamic and unreified nature of java generics is such that several
> valid systems I have encountered are impossible to properly express.
> Likewise, several systems I have tried to debug using generics have been
> found to have unsound generic type systems due to the language not
> enforcing proper static typing.
> IMHO Java is not a good language to use as an example when trying to make
> a case for changing the behavior of generics.
> -DW
> On Jan 12, 2016, at 6:47 PM, Howard Lovatt via swift-evolution <
> swift-evolution at swift.org> wrote:
> Yes you can annotate for covariance, invariance, and contravariance, both
> Java and Scala, allow all three. The problem is that the code becomes
> splattered with variance annotations. The Java people themselves have
> publicly regretted this and wished that they had made covariance the
> default. If you look at generic code invariance and covariance are by far
> the most common requirements; this proposal would address these common use
> case without burdening the programmer.

  -- Howard.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160113/76b9789d/attachment.html>

More information about the swift-evolution mailing list