<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=""><br class=""><div><blockquote type="cite" class=""><div class="">On Jan 26, 2016, at 9:19 AM, Maximilian Hünenberger <<a href="mailto:m.huenenberger@me.com" class="">m.huenenberger@me.com</a>> wrote:</div><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class="">Am 25.01.2016 um 23:58 schrieb David Waite <<a href="mailto:david@alkaline-solutions.com" class="">david@alkaline-solutions.com</a>>:</div></div></blockquote><snip><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">To have an implicit array of type Array<Number> that's what I've thought.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">I see your point but since covariance and contra-variance is a big topic there is a thread which discusses this in more detail:</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">Make generics covariant - was: [swift-evolution] Make generics covariant and add generics to protocols</div></div></blockquote><div><br class=""></div>From what I’ve gathered the proposal for generic covariance is different. (I’m not super-keen on even exposing the functionality for generics still, but thats a side-point) :-)</div><div><br class=""></div><div><div>let a:[UInt8] = [1,2,3]</div><div>let b:Array<where .Element : Number> = a<br class=""><blockquote type="cite" class=""></blockquote></div></div><div>b[0]= Int(1234)</div><div><br class=""></div><div>In the proposal for generic covariance proposes a dynamic interface which would fail at runtime if unacceptable, as above. Most of the negative comments are that this does not allow one to write code which reasons about whether a method call will work or fail - array out of bounds can be avoided by manual array bounds checking, for instance. These sorts of undetectable runtime errors are what ErrorType is for, but you can’t retrofit throws behavior in based on the use of covariance either.</div><div><br class=""></div><div>In my proposal, the compiler would not allow such a statement to proceed - the subscript functionality would be hidden because it is unsafe. This is actually similar to how Java handles wildcard-based call-site variance.</div><div><br class=""></div><div>Then, by opening the existential type of element you can dynamically reason about whether the call should succeed or fail. e.g. something like:</div><div><br class=""></div><div><div><div>let a:[UInt8] = [1,2,3]</div><div>let b:Array<where .Element : Number> = a<br class=""><blockquote type="cite" class=""></blockquote></div></div></div><div><br class=""></div><div>typealias A = b.dynamicType</div><div>let c = b as! A</div><div><br class=""></div><div>typealias E = b.Element</div><div>let val = Int(1234) as? E {</div><div> c[0] = val</div><div>}</div><div>else { /* code to handle incompatible use */ }</div><div><br class=""></div><div>Since I used Java as an example, I’ll go into more detail on how this proposal is different:</div><div><br class=""></div><div>Java is a bit painful to have call-site variance in Java for four main reasons:</div><div>1. The error reporting is absolutely terrible</div><div>2. The generics system is not reified (it’s advisory), with a single implementation. The swift equivalent would be if the underlying only had a single kind of Array which held Any, and generics just added restrictions by the compiler onto the interface.</div><div>3. The generics system is incomplete. It is not possible to have arrays of generic types, for instance (a Java [ArrayList<Int>])</div><div>4. A type can be cast to any other generic constraint or even without generics with only warnings, which are maskable from being output by the compiler.</div><div><br class=""></div><div>Because of these, I’ve seen several large projects (I won’t name names, but two of them are under Apache) where the generics definitions were unsound, yet nobody noticed because the developers just cast off the generics system completely when they ran into an edge case. </div><div><br class=""></div><div>For further example, one common anti-pattern I’ve seen for example is the state anti pattern - I have an implementation of an interface/protocol which lets me define a specific state object type as well as operations that will return a typed state object back as a result, and expect that same state object on future requests.</div><div><br class=""></div><div>When working at the level of that interface, it is not possible for me to reason about the type of state object needed on requests, so all the requests defined that take in that typed state object will be hidden. Instead, people will cast to the non-generic version of the interface, which will accept any of the state objects, and pass this in. If you do this by calling a method which specifies the non-generic interface version, you don’t even need to write an explicit cast operator - but the compiler will still of course have to cast, and will still fail at runtime if it can’t.</div><div><br class=""></div><div>The only way to dynamically determine whether or not the state is appropriate is to do RTTI (runtime type inspection) to look at the return value of the method and see if your State object’s runtime type is compatible. I’ve never seen anyone attempt this, because often they are so used to Java’s generics model being incomplete that they assume any generics errors are because of Java, not their declared type system.</div><div><br class=""></div><div>-DW</div><div><blockquote type="cite" class=""><div class=""><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><blockquote type="cite" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div class=""><div class=""><br class=""></div><div class=""><snip, to respond later></div><div class=""><blockquote type="cite" class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">PS: Have you made a formal proposal already?</div></blockquote></div><br class=""><div class="">Not yet, I was hoping to get more feedback on the value of the idea before writing up all of the rules, which will take many hours of my time (to fail fast). There has been very little discussion so far.</div><div class=""><br class=""></div><div class="">My hope is to have a discussion on where the generics and constrained protocol systems should go for Swift 3 and beyond, but I suspect the core team is occupied by Swift 2.2 and the API guidelines discussion ATM. Type system changes are IMHO something that really warrant having a roadmap extending several releases into the future, and there are a number of ones being proposed by both the core team and evolution members (evolutioneers?) in general.</div><div class=""><br class=""></div><div class="">-DW</div></div></blockquote><br style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">We'll see. At least a better generics system is one of the main goals for Swift 3.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">- Maximilian</div></div></blockquote></div><br class=""></body></html>