[swift-evolution] Change subscripts to use colons

Tim Vermeulen tvermeulen at me.com
Mon Jul 11 17:29:14 CDT 2016


> On 12 Jul 2016, at 00:20, Jacob Bandes-Storch <jtbandes at 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 at swift.org <mailto:swift-evolution at 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 at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20160712/a07b11c3/attachment.html>


More information about the swift-evolution mailing list