[swift-evolution] Change subscripts to use colons

[James Froggatt]

Thanks for letting me know this has been tried before, I'm actually in the process of drafting the proposal now.


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.


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?’. 

They borrow parameter lists, borrowing syntax from functions.
They borrow read-write access, which I feel should in turn borrow syntax from properties.


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:

//subscript
subscript(_ position: Int) inout -> Element { get { … } set { … } }

//equivalent function
func item(at position: Int) inout -> Element { get { … } set { … } }

This would align them with functions better than the current syntax, by preserving the meaning of the  ‘->’ to match functions.

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.


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.

I'll continue the draft, to get some more feedback, but I'll be sure to point out the readability issue.



> On 11 Jul 2016, at 18:45, Chris Lattner <clattner at apple.com> wrote:
> 
> 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.
> 
> 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.
> 
> -Chris
> 
>> On Jul 10, 2016, at 10:04 PM, Patrick Pijnappel via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> 
>> Good point. A subscript basically a parameterized property, not a function. I'm in favor.
>> 
>> On Mon, Jul 11, 2016 at 9:18 AM, James Froggatt via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Currently, the signature is:
>> subscript(_ example: Int) -> Element {
>>     get { … }
>>     set { … }
>> }
>> 
>> The alternative, using a colon, would be:
>> subscript(_ example: Int) : Element {
>>     get { … }
>>     set { … }
>> }
>> 
>> Sorry if that wasn't clear.
>> 
>> This would be to better reflect the property-like nature of access.
>> 
>> From James F
>> 
>> On 10 Jul 2016, at 23:57, Brent Royal-Gordon <brent at architechies.com <mailto:brent at architechies.com>> wrote:
>> 
>> >> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> >>
>> >> 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.
>> >>
>> >> However, I think a colon is more suitable, since it implies the possibility to set the value.
>> >
>> > 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".
>> >
>> > --
>> > Brent Royal-Gordon
>> > Architechies
>> >
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160711/eaef51e3/attachment.html>