<div dir="ltr"><div>Another option for handling this occurred to me - an "export list" in the lexical block that usually declares getters, setters, and will/didSet:</div><div><br></div><div>class Thing {</div><div> var property: String {</div><div> [get, set]</div><div> }</div><div>}</div><div><br></div><div>It's somewhat like a "capture list" syntax but in the context of the accessor declarations. The function is that it explicitly declares which of the methods should be exposed to the outside world - much like the auto-generated methods for properties in Objective-C. There would be a defined naming scheme for generated methods, perhaps a way to override the default name for special cases, etc. The generated/exported funcs are then just like every other func declared on the type.</div><div><br></div><div>Is there a strong inclination on the internal team to add features like this only if they can apply as broadly as possible, all at once?<br></div><div><br></div><div>Mike</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span style="font-size:13px">This is something I'm looking into. Providing the getter is valuable, but setters are not usually very useful by themselves. With value types, you need the full property interface to be able to drill further down into the value and update part of the value, since you potentially need recursive writeback. Furthermore, the get/set protocol is inefficient for copy-on-write types, since it forces a temporary copy when doing partial updates; Swift's property model provides a third implicit "materializeForSet" accessor that preserves in-place update when going through abstractions such as overrideable class properties, properties in generics, or properties across resilience boundaries. There are even more shenanigans we're planning to make mutations through array slices and the like efficient too. To that end, I think the two things you want of a property are:</span><br>- its getter, since read-only access is definitely useful for things like `map`, and<br>- what i'll call its "lens", notionally a function T -> inout U, which captures the full property interface. You can apply the function in mutable contexts without sacrificing efficiency or composability, and derive the getter/setter functions fairly straightforwardly.</blockquote></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 16, 2015 at 6:59 PM, Joe Groff <span dir="ltr"><<a href="mailto:jgroff@apple.com" target="_blank">jgroff@apple.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">This is something I'm looking into. Providing the getter is valuable, but setters are not usually very useful by themselves. With value types, you need the full property interface to be able to drill further down into the value and update part of the value, since you potentially need recursive writeback. Furthermore, the get/set protocol is inefficient for copy-on-write types, since it forces a temporary copy when doing partial updates; Swift's property model provides a third implicit "materializeForSet" accessor that preserves in-place update when going through abstractions such as overrideable class properties, properties in generics, or properties across resilience boundaries. There are even more shenanigans we're planning to make mutations through array slices and the like efficient too. To that end, I think the two things you want of a property are:<div><br></div><div>- its getter, since read-only access is definitely useful for things like `map`, and</div><div>- what i'll call its "lens", notionally a function T -> inout U, which captures the full property interface. You can apply the function in mutable contexts without sacrificing efficiency or composability, and derive the getter/setter functions fairly straightforwardly.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>-Joe</div><div><br></div></font></span><div><div><blockquote type="cite"><div><div class="h5"><div>On Dec 13, 2015, at 4:34 PM, Michael Henson via swift-evolution <<a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a>> wrote:</div><br></div></div><div><div><div class="h5"><div dir="ltr">Swift-like full KVO/KVC as in Objective-C is a stated long-term goal for Swift's evolution. The 90% solution might be more straightforward:<br><br>class Example {<div> var member: String</div><div><br></div><div> func print() {</div><div> print(self.member)</div><div> }</div><div>}<br><br>var example = Example(member: "Hi!")<br><br>var example_print_method = example.print</div><div>example_print_method()</div><div>result:</div><div>Hi!<br><br></div><div>If there were a mechanism for referring to the getter and setter methods on the var member property as the same kind of self-capturing closures, it could make simple cases of data binding easier to implement:<br><br>var serializeFields = [<br> "member": example.member#get,<br>]<br><br>var deserializeFields = [</div><div> "member": example.member#set,</div><div>]<br><br>var broadcastValueTo = [</div><div> "memberValues": [</div><div> example.member#set,</div><div> example2.member#set,</div><div> example3.member#set,</div><div> ]</div><div>]</div><div><br></div><div>viewController.textField.onValueChanged(example.member#set)<br><br>Etc.<br><br>The "#" notation is just a placeholder for "whatever mechanism is decided upon", though it does seem to be available and using it postfix makes a first-glance sense to me in terms of the semantics of expressions.<br><br>Mike</div></div>
</div></div><span class=""><img src="https://u2002410.ct.sendgrid.net/wf/open?upn=RoDF4MveSEMYBIqIJA6ub1g8cOZ-2BVYvqV-2FqygPhjPn9K6-2B-2BOoX8WSqEt2FYNfGr-2Bo0FgLPaSF7hDgINEU71hRVCsib-2B9zXQL4WH71BGc5tKxvQo19hMI2AbNCeUXVCFyXV1i4OBUzt1th3tmC8E1El8-2BWVW4gsK5GxIoQ-2BAkHS0s471KGj-2FbEtVpB8q5NGaTc0sVRTjTSqBqQvRgjMom4A-3D-3D" alt="" width="1" height="1" border="0" style="min-height:1px!important;width:1px!important;border-width:0!important;margin-top:0!important;margin-bottom:0!important;margin-right:0!important;margin-left:0!important;padding-top:0!important;padding-bottom:0!important;padding-right:0!important;padding-left:0!important">
_______________________________________________<br>swift-evolution mailing list<br><a href="mailto:swift-evolution@swift.org" target="_blank">swift-evolution@swift.org</a><br><a href="https://lists.swift.org/mailman/listinfo/swift-evolution" target="_blank">https://lists.swift.org/mailman/listinfo/swift-evolution</a><br></span></div></blockquote></div><br></div></div></blockquote></div><br></div>