<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 <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> 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> if (bar.length < 100)<br></div><div> _bar = nil;<br></div><div> else<br></div><div> _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> private var _bar: String?<br></div> public var bar: String? {<br></div> get { return _bar }<br></div> set {<br></div> if (newValue?.characters.count ?? 0) < 100 {<br></div> _bar = nil<br><div> }<br></div><div> else {<br></div><div> _bar = newValue.copy() as! String<br></div><div> }<br></div><div> }<br><div> }<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);"> public var bar: String? {</span></div><span style="background-color: rgba(255, 255, 255, 0);"> didSet {<br></span></div><span style="background-color: rgba(255, 255, 255, 0);"> if (bar?.characters.count ?? 0) < 100 {<br></span></div><span style="background-color: rgba(255, 255, 255, 0);"> bar = nil<br></span><div><span style="background-color: rgba(255, 255, 255, 0);"> }</span></div><div><span style="background-color: rgba(255, 255, 255, 0);"> }<br></span><div><span style="background-color: rgba(255, 255, 255, 0);"> }<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> public var bar: String? {<br> var _bar: String?<br><br> get { return _bar }<br> set {<br> if (newValue?.characters.count ?? 0) < 100 {<br> _bar = nil<br><div> }<br></div><div> else {<br></div><div> _bar = newValue.copy() as! String<br></div><div> }<br></div> }<br> }<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> static var synchronizedBar: String? {<br></div><div> var queue = DispatchQueue(label: "Foo.synchronizedBar")<br></div><div> var bar: String?<br></div><div><br></div><div> get { return queue.sync { return bar } }<br></div><div> set { queue.sync { bar = newValue } }<br></div><div> }<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> one way to look at what you're proposing is <span style="background-color: rgba(255, 255, 255, 0);">essentially as </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>