Feels like an abuse of subscripting IMHO. I'm fine with parametrized properties
but the subscript doesn't quite fit in this case.
Sent from my Apple Watch
On Jul 11, 2016, at 23:24, David Hart via swift-evolution
<swift-evolution@swift.org> wrote:
> 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
>> <swift-evolution@swift.org> wrote:
>>
>>
>>> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch <jtban...@gmail.com> 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
>>> <swift-evolution@swift.org> 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
>>>> swift-evolution@swift.org
>>>> https://lists.swift.org/mailman/listinfo/swift-evolution
>>>>
>>>
>>
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>
> _______________________________________________
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution
