<div dir="ltr">@David,<div><br></div><div>You said "<span style="font-size:13px">developer messed up</span>" for runtime crashes. The developer messed up when the compiler finds a problem also. Its the same thing; if the compiler statically finds a problem or the runtime finds a problem, in both cases the "<span style="font-size:13px">developer messed up". The only difference is that one is found at compile time and the other is found at runtime.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">My own guide in order of importance is:</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px"> 1. Ideally it should be </span>type safe, i.e. the error is found either by the runtime of the compiler. Obviously some languages, C, Obj-C, C++, are not type safe, and you can write great programs in all 3 and therefore you can't say that type safe is mandatory. By extension calls in Swift to C etc. are not type safe and there are many such calls in any realistic Swift program, is this a problem? Not really.</div><div> 2. Ideally the compiler will catch errors. Ideally, because this saves on testing. However if this burdens the programmer greatly you have to consider is it worth while. Many people prefer dynamically typed languages for exactly this reason, they find declaring types more trouble than it is worth. IE they feel the extra time spent annotating with type information is not paid back in terms of reduced testing. This 'explicitly typing is a pain' meme is common these days and has resulted in languages like Swift that infer the type.</div><div><br></div><div>Combining these 2 points leads me to conclude that you should stick with type safety were you can, infer type were you can, and only annotate extra type information if that annotation increases programmer productivity. </div><div><br></div><div>Hence the proposal: its type safe, it infers type when it can, and for the stuff that isn't worth annotating for it runtime checks.</div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">Does that explain my reasoning?</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px"> -- Howard.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On 14 January 2016 at 10:13, David Waite <span dir="ltr"><<a href="mailto:david@alkaline-solutions.com" target="_blank">david@alkaline-solutions.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 Jan 13, 2016, at 4:02 PM, Austin Zheng via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> 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">Hi Howard,<div><br></div><div>Making generics covariant by default would add even more of a burden to users. They would need to check the type property of a generic object any time they wanted to mutate that generic object or risk their program terminating.</div><div><br></div><div>I don't think the fact that array accesses are checked at runtime is a good example:</div><div><br></div><div>1. The Swift team has stated that subscripting into an array returns a non-optional at least in part because of performance issues. (Unfortunately, I think this was mentioned on the old Apple developer forums, which are now inaccessible, so don't take my word for it until someone with more insight says so one way or another :).</div><div>2. The fact that this specific aspect of Swift is checked at runtime doesn't provide insight as to whether or not another aspect of Swift should be compile-time or runtime-checked; it just indicates that there exists the possibility of some checks being done at runtime (and every mainstream statically typed language performs runtime checks to some extent, this isn't a novel conclusion).<br></div><div>3. Checking that an array access is in bounds is trivial from a conceptual standpoint. The index needs to be at least 0 and at most the length of the array - 1.</div><div>4. The length of a Swift array is not part of the type contract, whereas the type enclosed within a generic type is. Swift doesn't have fixed-length arrays.</div></div></div></blockquote><div><br></div></span>One might even argue the array length check is a precondition rather than a dynamic behavior. A developer is forced not to rely upon the bounds checking behavior, because an out-of-bounds error crashes the application. “Code crashes” is not a useful dynamic behavior and probably should not be used as an example for other behavior except in limited “developer messed up” scenarios.<span class="HOEnZb"><font color="#888888"><br></font></span></div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-DW</div><br></font></span></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"> -- Howard.<br></div>
</div>