<div dir="ltr">@Sune,<div><br></div><div>Yes you can annotate in a C#/Scala fashion. But you have burdened the programmer and haven't added much. In almost all cases you want covariant and I am proposing that that requirement is so pervasive that we can just ignore the rest. At present in Swift you only have invariant and that is usable, if inconvenient at times.</div><div><br></div><div>Lets take your example of IComparable<in T> from C#. On the web page for this, <a href="https://msdn.microsoft.com/en-us/library/4d7sx9hd(v=vs.110).aspx">https://msdn.microsoft.com/en-us/library/4d7sx9hd(v=vs.110).aspx</a>, there is an example of temperature comparisons. Their own example is invariant, because almost all comparisons will be invariant.</div><div><br></div><div>Furthermore Microsoft chose to make Equatable<T> invariant. A strange choice heh. How come comparing using IComparable behaves differently than using Equatable? If you implement both, which Microsoft recommends, then you get invariance, because Equatable is invariant.</div><div><br></div><div>In Swift there is a strong emphasis on final classes and structs (that are final). Therefore you can't use contravariance with these final types. Therefore virtually everything is covered by covariance and I am proposing that this should be the default. If it is found latter that there are uses for invariant and contra variant then annotations for these could be added, however I am suggesting that since covariant is overwhelmingly the most useful then it should be the default.</div><div><br></div><div>Hope this explains my reasoning,</div><div><br></div><div> -- Howard.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2016 at 07:10, Sune Foldager <span dir="ltr"><<a href="mailto:cyano@me.com" target="_blank">cyano@me.com</a>></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"><br><div><span class=""><blockquote type="cite"><div>On 12 Jan 2016, at 10:45, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br><div><div style="word-wrap:break-word"><div style="margin:0px;line-height:normal"><font face="Menlo"><span style="font-size:11px">Currently you generics are invariant whereas function arguments etc. are covariant. I am suggesting that if the way generics are implemented is changed then they can be made covariant and that this will add considerable utility to Swift generics.</span></font></div></div></div></blockquote><div><br></div></span><div>What about contravariant scenarios? Examples from C#:</div><div><br></div><div>IEnumerable<out T> // covariant</div><div>since if S : T then we want IEnumerable<S> : IEnumerable<T></div><div><br></div><div>because IEnumerable<T> only returns T’s.</div><div><br></div><div>but then</div><div><br></div><div>IComparable<in T> // contravariant</div><div>since if S : T we definitely want IComparable<T> : IComparable<S></div><div><br></div><div>because IComparable<T> only takes T’s as input.</div><div><br></div><div>reversing either of the above would make the type system unsound.</div><div>Any variance be default can’t be sound, and I am strongly opposed to that.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Sune</div><div><br></div></font></span></div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> -- Howard.<br></div>
</div>