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 <[email protected]> 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
>> <[email protected] <mailto:[email protected]>> 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
>> <[email protected] <mailto:[email protected]>> 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 <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> >> On Jul 9, 2016, at 11:48 AM, James Froggatt via swift-evolution
>> >> <[email protected] <mailto:[email protected]>> 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
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> [email protected] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
