Sorry, the subscript part was responding to Jacob's comment of how ‘button[imageFor: .normal]’ could be used with current syntax.
I've just sent a pull request for this proposal, I mentioned exactly your suggestion in the ‘future directions’ section. https://github.com/MutatingFunk/swift-evolution/blob/aa1fd53ec62b162f4cdefa9bd3845e13ac6f0d8d/proposals/NNNN-use-colons-for-subscript-type-declarations.md <https://github.com/MutatingFunk/swift-evolution/blob/aa1fd53ec62b162f4cdefa9bd3845e13ac6f0d8d/proposals/NNNN-use-colons-for-subscript-type-declarations.md> > On 12 Jul 2016, at 11:23, Tim Vermeulen <[email protected]> wrote: > > I wasn’t suggesting named subscripts :) As you seem to have figured out, that > gets confusing pretty quickly. Writing `self.items[0 ... 1]` seems a bit > silly because the use of a subscript already implies items of some kind. So, > to be clear, I was suggesting computed properties that allow parameters in > round brackets, not in square brackets. > > I agree that this might not make Swift 3, but your proposal already brings > subscripts and computed properties closer together. What I’m suggesting is to > make their declarations equivalent apart from `subscript` vs `var > <variableName>`. As an example, this is what you’re proposing: > > struct ArrayWrapper<Element> { > var array: [Element] > > subscript(index: Int): Element { > get { return array[index] } > set { array[index] = newValue } > } > } > > and my suggestion would allow this: > > extension ArrayWrapper { > var element(at index: Int): Element { > get { return array[index] } > set { array[index] = newValue } > } > } > > var wrapper = ArrayWrapper(array: [1, 2, 3]) > wrapper.element(at: 1) = 5 > print(wrapper.array) // [1, 5, 3] > >> On 12 Jul 2016, at 11:24, James Froggatt <[email protected] >> <mailto:[email protected]>> wrote: >> >> 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 <[email protected] >> <mailto:[email protected]>> 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? >>> > >>> > >>> > >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
