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

[Pierre Monod-Broca]

It could be used in that kind of way too (illustrating with the ‘#' syntax suggestion):

class Foo {
    var name: String
}

let getter = Foo.name#get // (Foo) -> () -> (String)
let setter = Foo.name#set // (Foo) -> (String) -> ()

let foo = Foo(name: "f")
getter(foo)() // "f"
setter(foo)("g") // now foo.name == "g"


It might be the similar with struct:

struct Bar {
    var name: String
}

let getter = Bar.name#get // (Bar) -> () -> (String)
let setter = Bar.name#set // (inout Bar) -> (String) -> ()

var bar = Bar(name: "f") // note bar is a var
getter(bar)() // "f"
setter(&bar)("g") // now foo.name == "g"


Pierre

> Le 17 déc. 2015 à 03:59, Joe Groff via swift-evolution <swift-evolution at swift.org> a écrit :
> 
> 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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
> 
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org <mailto:swift-evolution at swift.org>
> https://lists.swift.org/mailman/listinfo/swift-evolution <https://lists.swift.org/mailman/listinfo/swift-evolution>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151217/c702ffae/attachment.html>