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

[Adrian Kashivskyy]

+1, I like this idea! I'm not sure if I like `#`, though – maybe the type should be inferred, much like when using `init`s?

> struct Foo {
> 	init(_: Int) {}
> 	init(_: String) {}
> }
> 
> // this infers the int setter
> let intInit: (Int) -> Foo = Foo.init
> 
> // this infers the string setter
> let stringInit: (String) -> Foo = Foo.init

Note that you cannot explicitly refer to a specific `init`. My proposal is to use the same technique when referring to getters and setters:

> struct Foo {
> 	let bar: Int
> }
> 
> // this just reads the value
> let value = Foo.bar
> 
> // this infers a getter
> let getter: () -> Int = Foo().bar
> 
> // this infers a setter
> let setter: (Int) -> Void = Foo().bar

Pozdrawiam – Regards,
Adrian Kashivskyy

> Wiadomość napisana przez Pierre Monod-Broca via swift-evolution <swift-evolution at swift.org> w dniu 14.12.2015, o godz. 09:25:
> 
> +1
> 
> I like the #get, #set suffixes.
> 
> I’m afraid the following would be a bit ambiguous
>>  - example.init(argument:Int, another:String)
>>  - example.subscript(index:Int)
> 
> Maybe with ‘#’ too
>  - example.init#argument:Int#another:String
>  - example.init#argument#another
>  - example.init#(argument:Int, another:String)
>  - example.subscript#index:Int
>  - example.subscript#Int
> 
> Pierre
> 
>> Le 14 déc. 2015 à 08:57, ilya via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> a écrit :
>> 
>> > Being able to refer to getters and setters is a good idea and aligns with being able to refer to initializers and methods.
>> > I would also add subscripts to the list if possible.
>> 
>> Great idea! Let's discuss syntax
>> 
>> How about 
>>  - example.get.member
>>  - example.set.member
>>  - example.init(argument:Int, another:String)
>>  - example.subscript(index:Int)
>> 
>> 
>> On Mon, Dec 14, 2015 at 3:49 AM, Marc Knaup via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> Wait, where is stated that KVO is a long-term goal for Swift? I might have missed that.
>> 
>> I find that one of Objective-C's most annoying features. It makes it really difficult to reason about code when things can happen unexpectedly left and right. It's the same issue with aspect-oriented programming.
>> 
>> I prefer explicit integration points like closures, delegates and alike.
>> Most times I used KVO in the past was to work around bugs or annoyances on iOS, like for example forcing a button stay enabled even when iOS disables it.
>> 
>> Also it's unlikely that all mutable properties will support observation automatically. That would require the optimizer to keep using dynamic dispatch for all of them which will hurt performance.
>> 
>> 
>> But I'm getting off-topic since your discussion is not about KVO nor about KVC.
>> 
>> Being able to refer to getters and setters is a good idea and aligns with being able to refer to initializers and methods.
>> I would also add subscripts to the list if possible.
>> 
>> On Mon, Dec 14, 2015 at 1:34 AM, 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>
>> 
>> 
>>  _______________________________________________
>> 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/20151216/ec8befa6/attachment-0001.html>