How about a proposal for named subscripts?
button.image[for: .normal] = image
defined using:
subscript image(for: UIControlState): UIImage? {
get { … }
set { … }
}
> On 12 Jul 2016, at 00:29, Tim Vermeulen via swift-evolution
> <[email protected]> wrote:
>
>
>> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch <[email protected]
>> <mailto:[email protected]>> wrote:
>>
>> When would you want to use this instead of something like `button[imageFor:
>> .normal]` ?
>
> All the time, basically. Primarily because IMO it doesn’t really make sense
> to make “image” part of the argument label for the control state - we just
> have to (using subscripts) because subscripts themselves can’t be named. I
> think most people would agree that
>
> let image = button.image(for: .normal)
>
> is more readable than
>
> let image = button[imageFor: .normal]
>
> and likewise, I would prefer
>
> button.image(for: .normal) = image
>
> over
>
> button[imageFor: .normal] = image
>
>> On Mon, Jul 11, 2016 at 3:00 PM, Tim Vermeulen via swift-evolution
>> <[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] <mailto:[email protected]>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> <https://lists.swift.org/mailman/listinfo/swift-evolution>
>>
>>
>
> _______________________________________________
> swift-evolution mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution