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]> 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] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
