<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">I think this is missing the point of type safety. Whether checking occurs at runtime or compile time is irrelevant. What I want is a programming language whose well-typed programs “don’t go wrong” (in the Robin Milner sense), not one that allows me to discover its own definition for “wrong”. What you call type safety is really just deferring errors until runtime, which defeats the purpose of even having one in the first place in my opinion. Java made a horrendous mistake in this case, regardless of how common is may be in actual programs, and I don’t think Swift needs to make the same. <div class=""><br class=""></div><div class="">I’ll put it simply: I would rather have a language that allows me to write a smaller class of safer programs than one that allows a larger class of flat-out wrong ones.<div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 13, 2016, at 8:05 PM, Howard Lovatt <<a href="mailto:howard.lovatt@gmail.com" class="">howard.lovatt@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div dir="ltr" class="">@Robert,<div class=""><br class=""></div><div class="">The behaviour you show for Java arrays is what I am proposing, but that isn't type unsafe. The type error is detected at runtime and is flagged with an ArrayStoreException. This is unlike C for example that would allow the store, at least with a cast, and would put into the array the address of the string. Therefore neither the proposal or Java is type unsafe, both are type safe and both detect type errors at runtime.</div><div class=""><br class=""></div><div class="">The question is whether protecting against this is worthwhile, not whether it can be protected against or not (it can be). Arrays are a good example, Swift takes the approach (like most languages) of checking the array size at runtime. But languages with dependent typing check the array size at compile time, i.e. a dependently typed language would detect this error:</div><div class=""><br class=""></div><div class=""><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo;" class=""><span style="color:rgb(187,44,162)" class="">let</span> array = [<span style="color:rgb(39,42,216)" class="">1</span>]</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="color:rgb(79,129,135)" class="">array</span><span style="" class="">[</span><span style="color:rgb(39,42,216)" class="">0</span><span style="" class="">] </span>// 1, OK</div><div style="margin: 0px; font-size: 11px; line-height: normal; font-family: Menlo; color: rgb(0, 132, 0);" class=""><span style="color:rgb(79,129,135)" class="">array</span><span style="" class="">[</span><span style="color:rgb(39,42,216)" class="">1</span><span style="" class="">] </span>// Error not detected by compiler but detected at runtime</div></div><div class=""><br class=""></div><div class="">because in such a language array would be typed as int array of size one, not int array of any size.</div><div class=""><br class=""></div><div class="">So the real question is in a language like Java, how many times do you get ArrayStoreException? In my own code I have never seen an array store exception! Why? Because contravariant writes are very rare. If you were to protect against contravariant writes you would be complicating the language for no practical gain, which I think is a bad trade off.</div><div class=""><br class=""></div><div class="">Hope this explains the reasoning,</div><div class=""><br class=""></div><div class=""> -- Howard.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 14 January 2016 at 09:21, Developer <span dir="ltr" class=""><<a href="mailto:devteam.codafi@gmail.com" target="_blank" class="">devteam.codafi@gmail.com</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto" class=""><div class="">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 class=""><br class=""></div><div class="">Integer[] arr = [2, 4, 6, 8, 10];</div><div class="">Object[] orr = arr;</div><div class="">orr[0] = "crash bang";</div><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">I am, however, a fan of generic protocols. They seem like an orthogonal concept given the first part here though.<br class=""><br class=""><div class="">~Robert Widmann</div></div><div class=""><br class="">2016/01/13 17:03、Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>> のメッセージ:<br class=""><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><div class="h5"><div dir="ltr" class="">@Thorsten,<div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">Hope this explains the thought process,</div><div class=""><br class=""></div><div class=""> -- Howard.</div></div><div class="gmail_extra"><br class=""><div class="gmail_quote">On 13 January 2016 at 16:50, Thorsten Seitz <span dir="ltr" class=""><<a href="mailto:tseitz42@icloud.com" target="_blank" class="">tseitz42@icloud.com</a>></span> wrote:<br class=""><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 class="">
<span class=""><br class="">
> Am 13.01.2016 um 02:47 schrieb Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>>:<br class="">
><br class="">
> 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 class="">
<br class="">
</span>Ceylon uses a different approach which is variance annotations at the definition site.<br class="">
This restricts the possible usage of the type parameters to appropriately variant positions.<br class="">
<br class="">
This migt be a better way to deal with variance.<br class="">
<span class=""><font color="#888888" class=""><br class="">
-Thorsten</font></span></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class=""> -- Howard.<br class=""></div>
</div>
</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="min-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" class="">
</div></blockquote><span class=""><blockquote type="cite" class=""><div class=""><span class="">_______________________________________________</span><br class=""><span class="">swift-evolution mailing list</span><br class=""><span class=""><a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote></span></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="gmail_signature"> -- Howard.<br class=""></div>
</div>
</div></blockquote></div><br class=""></div></div></body></html>