<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div>It does indeed make the type system unsound in some cases. You have chosen one particular variance direction because it is convenient. A classic counterexample is Java making Arrays covariant by default. So this works</div><div><br></div><div>Integer[] arr = [2, 4, 6, 8, 10];</div><div>Object[] orr = arr;</div><div>orr[0] = "crash bang";</div><div><br></div><div>And crashes at runtime. For that, I must give this part of the proposal a strong -1. Any amount of type safety I have to give up in the name of convenience is far too much.</div><div><br></div><div>I am, however, a fan of generic protocols. They seem like an orthogonal concept given the first part here though.<br><br><div>~Robert Widmann</div></div><div><br>2016/01/13 17:03、Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> のメッセージ:<br><br></div><blockquote type="cite"><div><div dir="ltr">@Thorsten,<div><br></div><div>It doesn't make the type system unsound; the types are mostly checked at compile time but some are runtime checked, either way the types are checked and therefore the type system is sound. I have posted an example of array runtime type checking in a previous response.</div><div><br></div><div>You can annotate variance, but this generally adds a lot of clutter to the code (see some typical Java code that uses generics you will see stuff like ? extends Type everywhere). In other languages like Scala the annotation is less visually intrusive, because they use shorter syntax and because it is annotated at declaration site rather than use site, but it is still there.</div><div><br></div><div>I think Swift arrays are a good example of partially static and partially runtime checked. The content is statically typed but the size is runtime typed. Other languages do type both the content and the size (see Dependent Typing on Wiki), however at some considerable burden on the programmer. </div><div><br></div><div>Hope this explains the thought process,</div><div><br></div><div> -- Howard.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 13 January 2016 at 16:50, Thorsten Seitz <span dir="ltr"><<a href="mailto:tseitz42@icloud.com" target="_blank">tseitz42@icloud.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Strong -1 from me as well for making the type system unsound.<br>
<span class=""><br>
> Am 13.01.2016 um 02:47 schrieb Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>>:<br>
><br>
> 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<br>
<br>
</span>Ceylon uses a different approach which is variance annotations at the definition site.<br>
This restricts the possible usage of the type parameters to appropriately variant positions.<br>
<br>
This migt be a better way to deal with variance.<br>
<span class="HOEnZb"><font color="#888888"><br>
-Thorsten</font></span></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> -- Howard.<br></div>
</div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=NX5pLVYXK-2FsoGvk-2BsN3ORSjM6f2-2BhaPL1hRr1LvA764W188Y4hXkZci0axvp1rUqknkfjhEEe0vXHLEB6J03VkYcVNX7ET3HQQnfCPaYb2REvCV4R1bKYzVxnTDil2420QDCaP3r5Bg-2Bz4OSuzU7nCwFa4vgm6wLiFpk6HgCxgGOItTHcGyPzazkfFtcPeSska7Vbim8jn5Ckafmk-2B8pNkpmIKx9smOZcSu3OedbvZA-3D" alt="" width="1" height="1" border="0" style="height:1px !important;width:1px !important;border-width:0 !important;margin-top:0 !important;margin-bottom:0 !important;margin-right:0 !important;margin-left:0 !important;padding-top:0 !important;padding-bottom:0 !important;padding-right:0 !important;padding-left:0 !important;">
</div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></body></html>