<div dir="ltr">I should be clear, I am not proposing the Java way. I haven&#39;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 systems.<div><br></div><div>However since it is only tested in the sort of code I write it could be that I haven&#39;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 approach?</div><div><br></div><div>Hope you can find a suitable example,</div><div><br></div><div> -- Howard.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 January 2016 at 13:07, David Waite <span dir="ltr">&lt;<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">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.<div><br></div><div>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.</div><div><br></div><div>IMHO Java is not a good language to use as an example when trying to make a case for changing the behavior of generics.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-DW</div></font></span><span class=""><div><div><br><div><blockquote type="cite"><div>On Jan 12, 2016, at 6:47 PM, Howard Lovatt via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>&gt; wrote:</div><br><div><div dir="ltr" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">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.</div></div></blockquote></div><br></div></div></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature">  -- Howard.<br></div>
</div>