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]> 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
