I've added one of my original points to the motivation section: ‘[The arrow] implies that subscripts have the full capabilities of functions, such as the ability to throw. If throwing functionality were to be added to accessors, it is likely the specific get/set accessor would be annotated. In this case, the effects on a subscript's ‘function signature’ could become a source of confusion.’
Also, removed the second ‘mental stumbling block’ line. > On 11 Jul 2016, at 21:01, James Froggatt <[email protected]> wrote: > > > I've written up a draft proposal, suggestions or improvements are welcome, > especially relating to the title. > > > > __Change subscript declarations to use a colon__ > > --Introduction-- > > Currently, subscript declarations follow the following model: > > subscript(externalName internalName: ParamType) -> ElementType { > get { … } > set { … } > } > > The initial keyword ‘subscript’ is followed by a parameter list, followed by > an arrow to the accessed type. > > > --Motivation-- > > The arrow, borrowed from function syntax, is very much out of place in this > context, and so can act as a mental stumbling block. > > Subscripts act like parameterised property accessors. This means, like a > property, they can appear on the left hand side of an assignment, and values > accessed through subscripts can be mutated in-place. The colon has precedent > in declaring this kind of construct, so it makes sense to reuse it here. > > --Proposed solution-- > > A simple replacement of ‘->’ with ‘:’ in the declaration syntax. > > --Detailed design-- > > This would change the above example to look like the following: > > subscript(externalName internalName: ParamType) : ElementType { > get { … } > set { … } > } > > > --Impact on existing code-- > > Existing code would have to update subscripts to use a colon. This can be > automated in a conversion to Swift 3 syntax. > > > --Potential hazards-- > > Use of colons could have a negative effect on readability. This largely > depends on coding style, which can match either of the following: > > subscript(_ example: Type) : ElementType > > subscript(_ example: Type): ElementType > > This issue is most apparent in the latter example, which omits the leading > space before the colon, as the colon blends into the closing bracket. > > However, the real-world effect of this change is hard to predict, and > subscript declarations are rare enough that the consequences of this change > are very limited. In addition, the current ‘->‘ syntax can already act as a > mental stumbling block. > > --Alternatives Considered-- > > We could leave the syntax as it is, or use an alternative symbol, such as > ‘:->’ or ‘<->’. > > We could also leave open the possibility of expanding function syntax with > ‘inout ->’. _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
