<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 would much rather have proper support for covariance/contravariance than pretty but unsound code. It's been stated in other threads that making things pretty is not, in and of itself, a Swift project goal.<div class=""><br class=""></div><div class="">I like most of the other proposals, although I think most of them are covered by the expanded Swift 3 generics system.</div><div class=""><br class=""></div><div class="">Austin<br class=""><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 31, 2015, at 5:32 PM, Howard Lovatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="content-type" content="text/html; charset=utf-8" class=""><div dir="auto" class=""><div class="">There is a significant downside to variance in Java and Scala, you have to annotate your code all over the place. This annotation completely clutters your code, much like Swift is a lot 'cleaner' than Java, all the annotations detract. You see the same effect in code that uses Java arrays which much 'cleaner' that code that uses `List` (which is the generic equivalent of an array and hence requires variance annotations).<br class=""><br class="">Sent from my iPad</div><div class=""><br class="">On 31 Dec 2015, at 5:00 PM, Kevin Ballard via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class=""><br class=""></div><blockquote type="cite" class=""><div class="">
<title class=""></title>
<div class="">As Félix said this is a lot of stuff to cram into one proposal, so much so that I admit I haven't even read it. But skimming it very briefly I found the two following suggestions:<br class=""></div>
<div class=""> </div>
<blockquote type="cite" class=""><div class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""><ol start="3" class=""><li class=""><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Allow covariant generic argument types with a runtime check that it is of the correct type</span><br class=""></li></ol></div>
</div>
</blockquote><div class="">...<br class=""></div>
<blockquote type="cite" class=""><div class=""><div style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0px;line-height:normal;" class=""><div class=""><ol start="1" class=""><li class=""><span class="highlight" style="background-color: rgba(255, 255, 255, 0)">Arrays and a like become covariant (with runtime type check for write) - like Java arrays but not Java Lists</span><br class=""></li></ol></div>
</div>
</div>
</blockquote><div class=""> </div>
<div class="">And this makes no sense. Why would you break variance? The only justification I can see from your email is "because Java Arrays behave this way", but if anything that's an argument not to do it. Java Arrays predate Java Generics, and so the only way to write polymorphic functions that operated on Arrays was to make Array covariant. But this is generally regarded as a mistake (although I suspect a necessary one). As you mentioned Java Lists don't behave this way, and that's because they learned from their mistake (also, with Generics the type could be safely invariant and functions that operate on it could express the variance directly).<br class=""></div>
<div class=""> </div>
<div class="">FWIW, Swift Arrays actually _are_ covariant anyway (just try passing a [SubClass] to a function that expects [BaseClass]). But not in the sense that Java Arrays are. Swift's Array is a value type, which means that if that function then appends a BaseClass instance to the array it got, that's perfectly safe as it's really just mutating a copy (whereas Java Arrays are like Obj-C's NSMutableArray i.e. a reference type). I believe this is modeled internally as simply being an implicit coercion from [U] to [T] whenever U <: T (but I'm not sure where this is actually defined in the code). And of course because this is a coercion, it produces a temporary, and you can't use temporaries with inout parameters, so that preserves the invariance of arrays passed as inout parameters such as mutating methods (although if you could pass a temporary it would still be safe because it would write back to that temporary instead of the original array; this would be very confusing though which is why it's disallowed).<br class=""></div>
<div class=""> </div>
<div class="">-Kevin Ballard<br class=""></div>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=Vm9j-2B2K6zLqxUFTO82XA8HV2TThDz5lA3-2F-2Fpeujw7DQMlzoAvfU3v-2FHLVVjEMmllklhdBD97IbncnG4NsEgcwLDmNxDjoyIOYZ6rQ67XV-2FX8aE5i0BhlfdLKIJo3pja0ExsgrYyrnGL7FW-2Fctv1pL-2BeADQx3RgcOf-2Fh0jq-2BgsLELMTwGd4C1zfwgsomqAp-2B-2FmeaS-2FMQGNiufzpMwcPj-2BCYkB3qsplXNi8Osy-2Bx2rSRQ-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;" class="">
</div></blockquote><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" class="">swift-evolution@swift.org</a></span><br class=""><span class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br class=""></div></blockquote>
<img src="https://u2002410.ct.sendgrid.net/wf/open?upn=7XtDdMHRjqIUi4tzSjSp2pWQIyxYdP6woIWn4vwV5geoGJwbspZkXyRyfSzaeWqpVmt2pmaIum2rIk0q1B3apvB-2FeJxmeV8Iq2zBL8SdajxDPjuE-2B2dHr-2BWfViubvgyMOE8eMZI1UT6BZhbnbTI-2BAV7rZQWqMqsubstvyPjmNgwNU-2F2QDTs-2B8hPhzIcX58WOPUIBeV9AF7NJRPI51Cb-2BwbBWqiwc0BQJVDg3bWy0NII-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;" class="">
</div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">https://lists.swift.org/mailman/listinfo/swift-evolution<br class=""></div></blockquote></div><br class=""></div></div></body></html>