<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 12 Jan 2017, at 22:37, Slava Pestov 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=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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=""><br class="Apple-interchange-newline">On Jan 12, 2017, at 9:53 AM, Chris Eidhof 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=""><div dir="ltr" class="">Ok, I've got a draft up as a gist: <a href="https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25" class="">https://gist.github.com/chriseidhof/6c681677d44903045587bf75fb17eb25</a><div class=""><br class=""></div><div class="">Before I submit it, could someone let me know if adding generics to subscripts would influence the ABI? ( still feel pretty clueless in that area).</div></div></div></blockquote><div class=""><br class=""></div>It won’t change the ABI of existing subscript calls, but if the standard library introduces new generic subscripts that replace older non-generic subscripts, it will impact ABI.</div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: 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-caps: 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="">Slava</div></div></blockquote><br class=""></div><div>Why are subscripts so different, anyway? One would think they are basically sugared functions, but they don’t support so many things that regular functions support. Not just syntax stuff, either - they also don’t support @inline(__always) for some reason…</div><div><br class=""></div><div>Where generic subscripts are concerned, there are a couple of different things to express:</div><div>- Generic parameter (I can understand various co-ordinates for the data)</div><div>- Generic return type (I can construct your preferred representation of the data)</div><div>- Generic setter type (I can set the data using various compatible types):</div><div><br class=""></div><blockquote style="margin: 0 0 0 40px; border: none; padding: 0px;" class=""><div><font face="Courier" class="">protocol MeaningfulToFoo {}</font></div><div><font face="Courier" class="">protocol ConstructableFromFoo {}</font></div><div><font face="Courier" class=""><br class=""></font></div><div><font face="Courier" class="">struct Foo {</font></div><div><font face="Courier" class=""> subscript<Index>(index: Index) where Index: SignedInteger {</font></div><div><font face="Courier" class=""> get<T> where T: ConstructableFromFoo { return T(self) }</font></div><div><font face="Courier" class=""> set<U> where T: MeaningfulToFoo { self.someProperty = newValue.someData }</font></div><div><font face="Courier" class=""> }</font></div><div><font face="Courier" class="">}</font></div></blockquote><div><br class=""></div><div>The syntax looks a bit awkward, though, IMO. I’m wondering if it might be better to have some kind of combined subscript + property behaviours (remember those?) and allow those to be generic instead. Subscripts and properties are very similar anyway - they are both bundles of functions to represent getting and setting data (not just regular-old “get” and “set”, either, but also magic stuff like “mutableAddressWithPinnedNativeOwner”). The only difference is that property getters can’t have parameters — which is something I would also like to see lifted one day (I believe I’ve even seen people asking for “named subscripts” due to the lack of this =P)</div><div><br class=""></div><div>- Karl</div><br class=""></body></html>