<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=""><div><blockquote type="cite" class=""><div class="">On Jan 12, 2017, at 11:23 PM, Slava Pestov via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:</div><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="">On Jan 12, 2017, at 7:05 PM, Karl Wagner <<a href="mailto:razielim@gmail.com" class="">razielim@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><br class=""><div class=""><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 class="" 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;"><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 class="" 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;"><br class=""></div><div class="" 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;">Slava</div></div></blockquote><br class=""></div><div class="">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></div></blockquote><div class=""><br class=""></div>Nice catch with @inline(__always). Please file a JIRA issue, since I’m actively working on this stuff now.</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="">Subscripts are a bit different from ordinary functions because they’re lvalues. You can call mutating members on the result of a subscript, or chain it with another property access or subscript. So the code path in SILGen is a little different than ordinary function calls.</div></div></blockquote><div><br class=""></div><div>I would put it a little differently. Subscripts are used to refer to a logical component of a value, the same way that a property is. Subscripts are obviously different from properties because they're parameterized by some sort of index, but otherwise they're very similar in the core sense that the expression by itself just abstractly refers to a component of another value, and it's *how that expression is used* that really determines its semantics. That is, "a[i]" would always be a very odd thing to have as a statement on its own, just like "pi" would be a very odd thing to have as a statement on its own — generally you're reading from it or writing to it, and which one exactly you're doing can result in very different code being executed. It's that contextual sensitivity that makes subscripts quite different from just "sugared functions".</div><br class=""><blockquote type="cite" class=""><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="">This is the reason subscripts cannot have default arguments also. With a bit of refactoring we can unify the code path for forming call arguments in ordinary calls and subscripts, and hopefully the default argument and generic cases will fall out naturally also.</div></div></blockquote><div><br class=""></div>Right. There isn't any particular reason that subscripts don't support default arguments; it's just a little extra work that we've never done.</div><div><br class=""></div><div><blockquote type="cite" class=""><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=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class="">Where generic subscripts are concerned, there are a couple of different things to express:</div><div class="">- Generic parameter (I can understand various co-ordinates for the data)</div><div class="">- Generic return type (I can construct your preferred representation of the data)</div><div class="">- Generic setter type (I can set the data using various compatible types):</div></div></div></blockquote><div class=""><br class=""></div>I think all of these should be expressed with a single generic signature on the subscript itself. The element type passed to the setter and returned from the getter should be the same IMO, otherwise it’s not clear how it will work.</div></div></blockquote><div><br class=""></div>Yes. It's quite important that any particular subscript reference is still a single consistent entity, even if generic; we would not want, say, a read-modify-write access to be able to somehow invoke the getter and setter at different generic arguments, or to traffic in different element types.</div><div><br class=""></div><div>I'm also not sure we'd ever want the element type to be inferred from context like this. Generic subscripts as I see it are about being generic over *indexes*, not somehow about presenting a polymorphic value.</div><div><br class=""></div><div>John.</div><div><br class=""><blockquote type="cite" class=""><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=""><br 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=""><br class=""></div><blockquote class="" style="margin: 0px 0px 0px 40px; border: none; padding: 0px;"><div class=""><font face="Courier" class="">protocol MeaningfulToFoo {}</font></div><div class=""><font face="Courier" class="">protocol ConstructableFromFoo {}</font></div><div class=""><font face="Courier" class=""><br class=""></font></div><div class=""><font face="Courier" class="">struct Foo {</font></div><div class=""><font face="Courier" class=""> subscript<Index>(index: Index) where Index: SignedInteger {</font></div><div class=""><font face="Courier" class=""> get<T> where T: ConstructableFromFoo { return T(self) }</font></div><div class=""><font face="Courier" class=""> set<U> where T: MeaningfulToFoo { self.someProperty = newValue.someData }</font></div><div class=""><font face="Courier" class=""> }</font></div><div class=""><font face="Courier" class="">}</font></div></blockquote><div class=""><br class=""></div><div class="">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 class=""><br class=""></div><div class="">- Karl</div><br class=""></div></div></blockquote></div><br class="" 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;"><span 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; float: none; display: inline !important;" class="">_______________________________________________</span><br 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=""><span 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; float: none; display: inline !important;" class="">swift-evolution mailing list</span><br 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=""><span 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; float: none; display: inline !important;" class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a></span><br 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=""><span 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; float: none; display: inline !important;" class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span></div></blockquote></div><br class=""></body></html>