<div dir="ltr">We ran into that annoying limitation too and worked around it by importing the module's .swift file containing the extension directly into each module relying on it. It's not pretty but it works.<div>I reported it at <a href="https://bugs.swift.org/browse/SR-4017">https://bugs.swift.org/browse/SR-4017</a> but now when searching through the evolution archives I found this nice thread which totally reflects our issue.<br></div><div><br></div><div>I'd still like to propose support for declaring only setters for a property!</div><div>It's valid to do in extensions to add a setter for a read-only property in the type to be extended:</div><div><br></div><div><pre class="inbox-inbox-code-java" style="margin-top:0px;margin-bottom:0px;padding:0px;max-height:30em;overflow:auto;white-space:pre-wrap;word-wrap:normal;color:rgb(51,51,51);font-size:12px;background-color:rgb(245,245,245)">extension CGRect {
<span class="inbox-inbox-code-keyword" style="color:rgb(0,0,145)">public</span> <span class="inbox-inbox-code-keyword" style="color:rgb(0,0,145)">var</span> height: CGFloat {
mutating set { size.height = newValue }
}
<span class="inbox-inbox-code-keyword" style="color:rgb(0,0,145)">public</span> <span class="inbox-inbox-code-keyword" style="color:rgb(0,0,145)">var</span> width: CGFloat {
mutating set { size.width = newValue }
}
}</pre></div><div><br></div><div>@Jordan Rose I understand your concern regarding introducing new ambiguities. In this case however there's no difference from the ambiguous getter problem we already have today or the ambiguous symbol errors you can get from using *any* extension symbol which collides with another module's extension. Resolving ambiguities is a distinct problem to be solved.</div><div><br></div><div>To increase the value of setter-only declarations I'd go even a step further:</div><div>Setter-only declarations are also allowed in subclasses to override only the setter of a property without having to override the getter just to call super's implementation. The same applies to protocol conformances where the getter would already be covered by a default implementation so the conforming type just has to provide a setter.</div><div>Also this is then completely analogous to overriding either just getXYZ() or setXYZ() functions as developers are used from most other languages, including ObjC.</div><div><br></div><div>It may happen that developers who are new to Swift try to declare just a setter for a *new* property in order to execute special logic there.</div><div>In that case the compiler would emit an error for not providing a getter can offer three quick-fixes:</div><div><ul><li>replace "(mutating) set" with "didSet"<br></li><li>replace "(mutating) set" with "willSet"<br></li><li>add "get {}" to provide a getter</li></ul></div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Feb 4, 2016 at 1:40 AM Jarod Long via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 3, 2016, at 15:23, Jordan Rose <<a href="mailto:jordan_rose@apple.com" class="gmail_msg" target="_blank">jordan_rose@apple.com</a>> wrote:</div><br class="m_-5282070049180012641Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">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 <i class="gmail_msg">really hard</i> to pick a particular module's <i class="gmail_msg">setter.</i></div></div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">Apologies if I'm overlooking something here.</div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">I think it would be better to just request that the width and height fields get setters, since they're <a href="https://github.com/apple/swift/blob/master/stdlib/public/SDK/CoreGraphics/CoreGraphics.swift#L172" class="gmail_msg" target="_blank">already being defined in Swift</a>. 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.</div></div></blockquote><div class="gmail_msg"><br class="gmail_msg"></div></div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.</div></div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg">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.</div></div><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg"><br class="gmail_msg"></div><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg"><div style="word-wrap:break-word" class="gmail_msg"><div class="gmail_msg">Best,</div><div class="gmail_msg">Jordan</div><div class="gmail_msg"><br class="gmail_msg"></div><br class="gmail_msg"><div class="gmail_msg"><blockquote type="cite" class="gmail_msg"><div class="gmail_msg">On Feb 3, 2016, at 14:30, Jarod Long via swift-evolution <<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br class="m_-5282070049180012641Apple-interchange-newline gmail_msg"><div class="gmail_msg"><div class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">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.<br class="gmail_msg"><br class="gmail_msg">Looking forward to your input!<br class="gmail_msg"><br class="gmail_msg">Jarod<br class="gmail_msg"><br class="gmail_msg">_______________________________________________<br class="gmail_msg">swift-evolution mailing list<br class="gmail_msg"><a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg"><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"></div></div></blockquote></div><br class="gmail_msg"></div>_______________________________________________<br class="gmail_msg">
swift-evolution mailing list<br class="gmail_msg">
<a href="mailto:swift-evolution@swift.org" class="gmail_msg" target="_blank">swift-evolution@swift.org</a><br class="gmail_msg">
<a href="https://lists.swift.org/mailman/listinfo/swift-evolution" rel="noreferrer" class="gmail_msg" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br class="gmail_msg">
</blockquote></div>