<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 20 Jul 2016, Chris Lattner wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">The review of "SE-0122: Use colons for subscript declarations " begins now and runs through July 24. The proposal is available here:<br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span><a href="https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md" class="">https://github.com/apple/swift-evolution/blob/master/proposals/0122-use-colons-for-subscript-type-declarations.md</a><br class=""><br class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* What is your evaluation of the proposal?<br class=""></div></div></blockquote><div><br class=""></div><div>I'm mildly in favour because I think (settable) subscripts are more similar to properties than functions. But is this change worth having in Swift 3? I'm a bit surprised it's discussed this late in the cycle.</div><div><br class=""></div><div>Here are some considerations on the topic:</div><div><br class=""></div><div>1. If we bring colons in, why not change the parentheses into brackets too? Like so:</div><div><br class=""></div><div><font face="Menlo" class=""> public subscript[index: Int]: Element</font></div><div><br class=""></div><div>2. If we change the arrows into colons but then later choose to make throwing subscripts possible, how could that be still done? Probable answer: by adding the `<font face="Menlo" class="">throws</font>` specifier to the getter or setter as needed.</div><div><br class=""></div><div>3. Do we want to address the fact that – unlike functions – subscript arguments currently have implicitly blank external names, i.e. that `<font face="Menlo" class="">subscript(at: Int)</font>` and `<font face="Menlo" class="">subscript(_ at: Int)</font>` are equivalent? I don't think we do; but if that's the case then it's probably a good idea to also make the declaration syntax less alike with functions. So that would be a small argument in favour of SE-0122.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Is the problem being addressed significant enough to warrant a change to Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>Probably not at this stage. I think this change could be introduced even post-Swift 3, although that would then require maintaining both syntaxes for an extended period of time.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* Does this proposal fit well with the feel and direction of Swift?<br class=""></div></div></blockquote><div><br class=""></div><div>I think so.</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?<br class=""></div></div></blockquote><div><br class=""></div><div>N/A</div><br class=""><blockquote type="cite" class=""><div class=""><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>* How much effort did you put into your review? A glance, a quick reading, or an in-depth study?<br class=""></div></div></blockquote></div><br class=""><div class="">A quick reading.</div><div class=""><br class=""></div><div class="">— Pyry</div><div class=""><br class=""></div></body></html>