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

[swift at lng.la]

> On Feb 3, 2016, at 15:23, Jordan Rose <jordan_rose at apple.com> wrote:
> 
> 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 I don't have a complete understanding of how disambiguation works, because it's not quite clear to me how disambiguating setters is harder than methods or properties. As far as I understand it, to disambiguate a symbol, you prefix it with the module name. I'm actually not sure how to disambiguate anything that isn't directly accessible in the current scope (where does the module name go?), so getters, setters, and methods seem equally difficult to disambiguate.

Apologies if I'm overlooking something here.

> 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.

Interesting -- thank you for the link! I was originally going to suggest a change in the Objective-C API translation thread, but I had assumed that the width and height properties came from a generic rule that automatically translated the CGRectGet___ functions and that making explicit translation rules for CGRect would be undesirable.

I would like to solve the general problem if there's a reasonable way to do so, since I do think there are applications outside of these specific properties. To use another CGRect example, you may want the midX/Y properties (among others) to be settable, but introducing built-in setters for all of these kinds of properties is likely not something we would want to do.

If it turns out that this isn't a feasible thing to do, then I think building these particular setters into Swift is the next best thing, but I'd like to explore the possibilities here for a bit before trying to go that route.

> Best,
> Jordan
> 
> 
>> On Feb 3, 2016, at 14:30, Jarod Long via swift-evolution <swift-evolution at swift.org <mailto: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 <mailto: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/e4af86a4/attachment.html>