[swift-evolution] [Draft proposal] Extending read-only properties with setters

[Jordan Rose]

This violates the "what if two people did this?" rule; while you might be able to disambiguate between two modules that define the same method or property, it seems really hard to pick a particular module's setter.

I think it would be better to just request that the width and height fields get setters, since they're already being defined in Swift <https://github.com/apple/swift/blob/master/stdlib/public/SDK/CoreGraphics/CoreGraphics.swift#L172>. If you want to attack the general problem, I think it would be better to come up with ways to disambiguate overloads that differ only by module.

Best,
Jordan


> On Feb 3, 2016, at 14:30, Jarod Long via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Swift extensions are fantastic for filling in gaps in an API, but they don't currently allow you to convert a read-only property into a read-write property by extending it with your own setter. I'd like to propose that an extension may contain a set-only computed property iff the extended type already has a getter for that property.
> 
> My specific motivation for this proposal stems from CGRect's translated API. If you frequently work with rects, it's very convenient to be able to access their x/y/width/height properties directly. It's easy to extend CGRect with x/y properties, but width and height are problematic because of the CGRectGetWidth and CGRectGetHeight functions that get imported as read-only width and height properties on CGRect.
> 
> If you extend CGRect with read-write width/height properties, they'll work within the module they're defined because the getters shadow the imported Objective-C versions, but using the getters in other modules becomes impossible due to ambiguity errors. If it was possible to only define the width/height setters, the ambiguity wouldn't exist.
> 
> This particular issue is pretty narrow, but it's moderately frustrating if you write a lot of layout code or do other work with rects, and I think this is just one of many situations where adding a setter to a property would be useful.
> 
> This proposal is somewhat related to the "support for pure setters" discussion, but since it doesn't involve the tradeoffs of introducing actual set-only properties, I feel that this warrants its own separate discussion.
> 
> Looking forward to your input!
> 
> Jarod
> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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