<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br></div><div>On Jan 13, 2017, at 11:27, Joseph Newton via swift-evolution &lt;<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>&gt; wrote:<br><br></div><blockquote type="cite"><div dir="ltr"><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div><div>Hi,<br><br></div>I've done a lot of Objective-C and have been been a fan of Swift since it's come out, however, there's a small feature of Objective-C that I would really like to see implemented in Swift:<br><br></div>In Objective-C you have a few options implementation-wise when creating properties for your class. You could use the <i>@synthesize </i>statement to have the compiler create the backing ivar along with the appropriate accessor methods<i> </i>or your could use the <i>@dynamic</i> statement to tell the compiler that you're going to create your own accessor methods and backing ivar (if needed).<br><br></div>Additionally, one could use the <i>@synthesize</i> statement to have the compiler create the backing ivar, and then they could create custom accessor methods to supply custom functionality or validation. I use this third case extensively in my Objecitve-C code but there's not a concise way of doing this in Swift.<br><br></div>For example, I might have an Objective-C implementation that looks like this:<br><br></div>@interface Foo : NSObject<br></div><div>@property (nullable, copy) NSString *bar;<br></div>@end<br><br></div>@implementation Foo<br></div><div>@synthesize bar = _bar; // Creates ivar '_bar'<br></div><div><br></div><div>- (void)setBar:(NSString *)bar {<br></div><div>&nbsp;&nbsp;&nbsp; if (bar.length &lt; 100)<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _bar = nil;<br></div><div>&nbsp;&nbsp;&nbsp; else<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; _bar = [bar copy];<br></div><div>}<br></div><div><br></div>@end<br><br></div>Currently, the only way to implement this in Swift - AFAIK - is as follows:<br><br></div>class Foo {<br></div>&nbsp;&nbsp;&nbsp; private var _bar: String?<br></div>&nbsp;&nbsp;&nbsp; public var bar: String? {<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; get { return _bar }<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set {<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (newValue?.characters.count ?? 0) &lt; 100 {<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; _bar = nil<br><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; _bar = newValue.copy() as! String<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br><div>&nbsp;&nbsp;&nbsp; }<br><div><div>}<br><br></div><div>Although this works, it isn't exactly glamorous. The main drawback of this implementation (unless intended) is that you now have any additional '_bar' variable accessible within the scope of your class. <br></div></div></div></div></div></blockquote><div><br></div><div><div><span style="background-color: rgba(255, 255, 255, 0);">I believe you can do this using didSet without the `_bar`:</span></div><div><div dir="ltr"><div><div><div><div><span style="background-color: rgba(255, 255, 255, 0);">class Foo {</span></div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;&nbsp;&nbsp; public var bar: String? {</span></div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp; didSet {<br></span></div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (bar?.characters.count ?? 0) &lt; 100 {<br></span></div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; bar = nil<br></span><div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }</span></div><div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></span><div><span style="background-color: rgba(255, 255, 255, 0);">&nbsp;&nbsp;&nbsp; }<br></span><div><span style="background-color: rgba(255, 255, 255, 0);">}</span></div></div></div></div></div></div><div><br></div><br><blockquote type="cite"><div dir="ltr"><div><div><div><div>My proposal is to allow stored properties in the declaration block of computed properties. For this example, the '_bar' declaration would simply be moved inside of the declaration block for 'bar':<br><br>class Foo {<br>&nbsp;&nbsp;&nbsp; public var bar: String? {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; var _bar: String?<br><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; get { return _bar }<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; if (newValue?.characters.count ?? 0) &lt; 100 {<br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; _bar = nil<br><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; else {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; _bar = newValue.copy() as! String<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br></div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; }<br>&nbsp;&nbsp;&nbsp; }<br>}<br><br></div><div>Only the getter and setter methods of 'bar' are allowed to access and modify the stored '_bar' property. My proposal would also allow for multiple stored properties of varying types within the scope of a single computed property. This would also simply atomic synchronization for single variables:<br><br></div><div>class Foo {<br></div><div>&nbsp;&nbsp;&nbsp; static var synchronizedBar: String? {<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; var queue = DispatchQueue(label: "Foo.synchronizedBar")<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; var bar: String?<br></div><div><br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; get { return queue.sync { return bar } }<br></div><div>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; set { queue.sync { bar = newValue } }<br></div><div>&nbsp;&nbsp;&nbsp; }<br></div><div>}<br><br></div><div>Are there any suggestions or arguments, for or against, for this proposal?<br></div></div></div></div></div></blockquote><div><br></div><div>It's an interesting idea, for sure. Because of the persistent storage required for `_bar`, I <i>think</i>&nbsp;one way to look at what you're proposing is <span style="background-color: rgba(255, 255, 255, 0);">essentially as&nbsp;</span>a way to allow for a variable to be declared publicly as one type, be implemented as another (anonymous, in this case) type under the hood, and to specify a mechanism for automatically converting between the two types.</div><div><br></div><div>- Dave Sweeris</div><div><br></div></body></html>