<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="">On Jan 28, 2016, at 9:25 PM, Joe Groff <<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>> wrote:<br class=""><div><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="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" class=""><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><div class="">+1. I like this syntax too, and with Joe’s other proposed extensions, it would all fit together nicely. Anyone interested in writing up a proposal?</div></div></div></div></blockquote><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="">One other tweak worth considering: instead of subscript being defined on a tuple as returning a common type, a more modest proposal would be that subscript is defined on tuples that:</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="">a) have no element labels.</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="">b) all have the same element type.</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="">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></blockquote><br class=""></div><div class="">I'm not sure this prevents anything, since labeled tuples implicitly convert to unlabeled tuples, and tuples support structural subtyping, so (Derived, Derived) is-a (Base, Base) is-an (Any, Any). Both of those type rules might be worth reconsidering on their own, of course, but otherwise you could still backdoor your way into subscripting a heterogeneous and/or labeled tuple via those conversions.</div></div></div></blockquote><br class=""></div><div>Right, I’d much rather see:</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>let v = (someHeterogenousTuple as (4 x Any))[i]</div><div class="">Rather than:</div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>let v = someHeterogenousTuple[i]</div><div class=""><br class=""></div><div class="">given that the subscripting syntax is intended to be an efficient “array index” operation. I’m uncomfortable with an expensive representation-transforming operation that potentially involves heap allocation (when the tuple element is a struct larger than the Any existential rep) happening accidentally.</div><div class=""><br class=""></div><div class="">That said, perhaps there is a middle ground: we can use the same rules we use for array literals since array literals also don’t merge to Any as their common type. I see no concerns with using the common type for a heterogenous tuple of classes that have a common base class, for example, because that won’t be a representation change.</div><div class=""><br class=""></div><div class="">That said, I don’t think this will be a very important use case, so I’d be happy with subsetting that out of the base proposal, and adding it when there is a specific motivation for it.</div><div class=""><br class=""></div><div class="">-Chris</div></body></html>