<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="">Thanks for letting me know this has been tried before, I'm actually in the process of drafting the proposal now.<div class=""><br class=""></div><div class=""><br class=""></div><div class="">I agree about the issue of the colon's visual weight, it's not ideal. On the other hand, I still find myself doing a mental double-take when reading ‘->’ in subscript declarations.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">For subscripts, I think it's less a matter of ‘what existing category do we put them in?’, so much as it is about ‘what aspects do they borrow?’, and ‘how can we keep syntax consistent?’. </div><div class=""><br class=""></div><div class="">They borrow parameter lists, borrowing syntax from functions.</div><div class="">They borrow read-write access, which I feel should in turn borrow syntax from properties.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">If we did want to align subscripts with function declarations, then we would be deciding on a new syntax for functions which allows get-set semantics, such as the following:</div><div class=""><br class=""></div><div class="">//subscript</div><div class="">subscript(_ position: Int) inout -> Element { get { … } set { … } }</div><div class=""><br class=""></div><div class="">//equivalent function</div><div class="">func item(at position: Int) inout -> Element { get { … } set { … } }</div><div class=""><br class=""></div><div class="">This would align them with functions better than the current syntax, by preserving the meaning of the ‘->’ to match functions.</div><div class=""><br class=""></div><div class="">But it's worth pointing out that even read-only subscripts can't throw - the similarity to functions is only superficial, and largely a result of the current syntax. These are very much properties with parameters.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class="">I cannot argue with an internal trial, and I think that's a bit of a flaw of this mailing list system - many people making these proposals will not see these changes until they are out in the public. Certainly the proposal to remove argument labels could have benefitted from this kind of trial.</div><div class=""><br class=""></div><div class="">I'll continue the draft, to get some more feedback, but I'll be sure to point out the readability issue.</div><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><br class=""><div><blockquote type="cite" class=""><div class="">On 11 Jul 2016, at 18:45, Chris Lattner <<a href="mailto:clattner@apple.com" class="">clattner@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="">FWIW, we actually tried this at one point with exactly this rationale, but pulled it back out. In short, subscript decls are half way between func decls and var decls. Reasonable arguments can be made to align with either of them, but arrow “looks” better.<div class=""><div class=""><br class=""></div><div class="">The problem which caused us to pull back and stick with arrow is that the return value is very primary to the functioning of the subscript, and colon reduced the visual weight of it, making it harder to pull out of code. The secondary issue is that the structure of a subscript definition is very strongly aligned with that of func decls, and changing this reduced that.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Jul 10, 2016, at 10:04 PM, Patrick Pijnappel 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="">Good point. A subscript basically a parameterized property, not a function. I'm in favor.</div><div class="gmail_extra"><br class=""><div class="gmail_quote">On Mon, Jul 11, 2016 at 9:18 AM, James Froggatt via swift-evolution <span dir="ltr" class=""><<a href="mailto:swift-evolution@swift.org" target="_blank" class="">swift-evolution@swift.org</a>></span> wrote:<br class=""><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Currently, the signature is:<br class="">
subscript(_ example: Int) -> Element {<br class="">
get { … }<br class="">
set { … }<br class="">
}<br class="">
<br class="">
The alternative, using a colon, would be:<br class="">
subscript(_ example: Int) : Element {<br class="">
get { … }<br class="">
set { … }<br class="">
}<br class="">
<br class="">
Sorry if that wasn't clear.<br class="">
<br class="">
This would be to better reflect the property-like nature of access.<br class="">
<br class="">
From James F<br class="">
<div class="HOEnZb"><div class="h5"><br class="">
On 10 Jul 2016, at 23:57, Brent Royal-Gordon <<a href="mailto:brent@architechies.com" class="">brent@architechies.com</a>> wrote:<br class="">
<br class="">
>> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a>> wrote:<br class="">
>><br class="">
>> Subscripts are a hybrid of properties and functions, since they have a parameter list, as well as getters and setters, so use of either symbol will be unusual in this case.<br class="">
>><br class="">
>> However, I think a colon is more suitable, since it implies the possibility to set the value.<br class="">
><br class="">
> Can you show us an example of the current syntax and your proposed replacement? I'm not sure what you actually mean by "use colons".<br class="">
><br class="">
> --<br class="">
> Brent Royal-Gordon<br class="">
> Architechies<br class="">
><br class="">
_______________________________________________<br class="">
swift-evolution mailing list<br class="">
<a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class="">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" target="_blank" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="">
</div></div></blockquote></div><br class=""></div>
_______________________________________________<br class="">swift-evolution mailing list<br class=""><a href="mailto:swift-evolution@swift.org" class="">swift-evolution@swift.org</a><br class=""><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class=""></div></blockquote></div><br class=""></div></div></div></div></blockquote></div><br class=""></div></body></html>