<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 Feb 9, 2016, at 14:42, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="">jordan_rose@apple.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 9, 2016, at 13:52, Dave 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 style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Feb 9, 2016, at 12:57, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@apple.com</a>> wrote:</div><div class=""><meta http-equiv="Content-Type" content="text/html charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class="">On Feb 9, 2016, at 11:33 AM, <a href="mailto:davesweeris@mac.com" class="">davesweeris@mac.com</a> wrote:<br class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class="">This would solve the fixed size array use-case, be much easier to implement, and not have surprising performance issues promoting things to Any. It is also consistent with the fact that we don’t infer the type of [Int(), Float()] to [Any].</div><div class=""><br class=""></div><div class="">-Chris</div></div></div></blockquote></div><div class=""><br class=""></div><div class="">(Sorry to go so far back… I started replying to this on probably the 29th and somehow forgot about it.)</div><br class=""><div class=""><div class=""><div class="">Out of curiosity, why would the subscript of non-homogeneous tuple have to return an "Any”? If we declare this:</div><div class=""><span style="color: rgb(211, 54, 130); font-family: 'Fira Mono';" class="">let</span><font color="#93a1a1" face="Fira Mono" class=""> grohl = (</font><span style="color: rgb(108, 113, 196); font-family: 'Fira Mono';" class="">0</span><font color="#93a1a1" face="Fira Mono" class="">, </font><font color="#dc322f" face="Fira Mono" class="">“foo</font><font face="Fira Mono" class=""><font color="#dc322f" class="">”</font><font color="#93a1a1" class="">, </font></font><font color="#dc322f" face="Fira Mono" class="">“fighters</font><font face="Fira Mono" class=""><font color="#dc322f" class="">”</font><font color="#93a1a1" class="">, </font></font><span style="color: rgb(108, 113, 196); font-family: 'Fira Mono';" class="">0.0</span><font color="#93a1a1" face="Fira Mono" class="">)</font></div><div class=""><div style="margin: 0px; line-height: normal;" class=""><div style="margin: 0px; line-height: normal;" class=""><div style="margin: 0px; line-height: normal;" class=""><br class=""></div><div style="margin: 0px; line-height: normal;" class="">Why couldn’t subscript (and $0 in map, for that matter) return a type that’s the “intersection” of Int, String, and Double?</div></div></div></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Swift has no such intersection type. The closes analogs we have are Any (or if you allow boxing, NSObject/NSValue).</div></div></div></div></blockquote></div><br class=""><div class="">I know. My round-about point was that, if my assumption about how that part of the compiler works is correct, it wouldn’t be hard to add the functionality. At least from the point of view of how to check if the code is correct. Admittedly, I was only thinking in terms of how one would go about extending map() to tuples. I haven’t considered the implications of allowing the “intersection” to be assigned to a variable or returned from a function, or what the syntax could/should be for interacting with such a type outside of the closure passed to map().</div><div class=""><br class=""></div><div class="">If it isn’t out of scope or just a non-starter, I’d like to explore the idea here (or in a different thread). Seems like it could make tuples in general, and specifically generic tuples, a lot more powerful.</div></div></div></blockquote><br class=""></div><div class="">Types aren't just bags of operations, which means that taking the intersection of arbitrary types isn't meaningful. Similarly, generics aren't templates to be instantiated, meaning that there has to be a run-time representation of a "value of intersection type".</div><div class=""><br class=""></div><div class="">The constructs that carries the right meaning in Swift are protocols, and in theory you could intersect the protocols of the various types. In practice, though, the current model doesn't have a good way to actually do this, since not all protocols can be used as types of values, and finding the protocol-intersection of N types is a needless amount of extra work for the compiler anyway.</div><div class=""><br class=""></div><div class="">Jordan</div></div></div></blockquote></div>Ah, it’s a non-starter then… Or at the very least *much* more difficult than I’d thought. Thank you :-)<div class=""><br class=""></div><div class=""><div class="">- Dave Sweeris</div></div><div class=""><br class=""></div></body></html>