[swift-evolution] Proposal: Expose getter/setters in the same way as regular methods

[Michael Henson]

Another option for handling this occurred to me - an "export list" in the
lexical block that usually declares getters, setters, and will/didSet:

class Thing {
  var property: String {
    [get, set]
  }
}

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.

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?

Mike


> 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:
> - its getter, since read-only access is definitely useful for things like
> `map`, and
> - 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.


On Wed, Dec 16, 2015 at 6:59 PM, Joe Groff <jgroff at apple.com> wrote:

> 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:
>
> - its getter, since read-only access is definitely useful for things like
> `map`, and
> - 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.
>
> -Joe
>
> On Dec 13, 2015, at 4:34 PM, Michael Henson via swift-evolution <
> swift-evolution at swift.org> wrote:
>
> 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:
>
> class Example {
>   var member: String
>
>   func print() {
>     print(self.member)
>   }
> }
>
> var example = Example(member: "Hi!")
>
> var example_print_method = example.print
> example_print_method()
> result:
> Hi!
>
> 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:
>
> var serializeFields = [
>   "member": example.member#get,
> ]
>
> var deserializeFields = [
>   "member": example.member#set,
> ]
>
> var broadcastValueTo = [
>   "memberValues": [
>      example.member#set,
>      example2.member#set,
>      example3.member#set,
>   ]
> ]
>
> viewController.textField.onValueChanged(example.member#set)
>
> Etc.
>
> 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.
>
> Mike
> _______________________________________________
> swift-evolution mailing list
> 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/20151218/4d467efc/attachment.html>