Then it kinda looks like your subscripting a property called `image`, doesn’t it?
> On 12 Jul 2016, at 08:24, David Hart <[email protected]> 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 >> <[email protected] <mailto:[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] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
