> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch <[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
