[swift-evolution] Change subscripts to use colons

[James Froggatt]

I like the idea of ‘named parameterised properties’, but I don't see it happening for Swift 3, which is unfortunate since it would tidy up quite a few APIs.
If this feature does get added, updating getter functions to them would be a non-breaking change, so maybe it would be possible to deprecate setImage(_:for:) and have a long trasition period.

The idea of using subscripts for this kind of property is interesting, but currently they don't show up in autocomplete, so working with labelled subscripts is tricky.

This does raise the question of where to draw the line with subscripts - should they only be used where the container itself is the base name of the ‘function’? But if this is the case:

self.items[0 ... 1] //good

self.item[0] //good

self.items[0] //bad, reads as ‘items 0’, not the grammatical term ‘item 0’

You could say we're already misusing them.

> On 11 Jul 2016, at 23:00, Tim Vermeulen <tvermeulen at me.com> wrote:
> 
> Slightly related to this, I would really love to have non-subscript parameterized properties. It would allow us to write
> 
> button.image(for: .normal) = image
> 
> instead of
> 
> button.setImage(image, for: .normal)
> 
> The same can be achieved through subscripts, but it’s not always as nice. It would bring subscripts and computed properties closer together, which also seems to be the goal of your proposal. Perhaps the two ideas could be combined?
> 
> > 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.
> > 
> > 
> > In the future, if we add throwing getters/ setters:
> > 
> > subscript(_ position: Int) ->Element {
> > get {
> > return …
> > }
> > throwing set {
> > …
> > }
> > }
> > 
> > Should this require ‘throws ->Element’? Using a colon also removes this potentially confusing case.
> > 
> > 
> > Thoughts?
> > 
> > 
> > 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160712/cfe625ed/attachment.html>