[swift-evolution] Change subscripts to use colons

[Tim Vermeulen]

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 <james.froggatt at me.com> 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 <tvermeulen at me.com <mailto: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/d10292a1/attachment.html>