[swift-evolution] [Discussion] Referencing the Objective-C selector of property getters and setters

Chris Lattner clattner at apple.com
Wed Feb 24 22:41:49 CST 2016


On Feb 24, 2016, at 4:21 PM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
> 
> As was discussed in a previous thread, here is my proposal for allowing the new #selector syntax to support referencing property getter and setters. Does anybody have any comments before I push the proposal forward?

+1, proposal LGTM.

-Chris

> 
> David.
> 
> Referencing the Objective-C selector of property getters and setters
> 
> Proposal: TBD
> Author(s): David Hart <https://github.com/hartbit>
> Status: TBD
> Review manager: TBD
>  <https://github.com/hartbit/swift-evolution/tree/objc-property-selectors#introduction>Introduction
> 
> Proposal SE-0022 <https://github.com/apple/swift-evolution/blob/master/proposals/0022-objc-selectors.md> to reference Objective-C selectors for methods was accepted and implemented. Unfortunately, it does not allow referencing the getter and setter methods of properties. This proposal seeks to provide a design to reference those methods for the Swift 3.0 timeframe.
> 
> The idea for this proposal was originally discussed on the following Swift-evolution thread: here <http://article.gmane.org/gmane.comp.lang.swift.evolution/7614>
>  <https://github.com/hartbit/swift-evolution/tree/objc-property-selectors#motivation>Motivation
> 
> The #selector feature is very useful but does not yet cover all cases. Accessing poperty getter and setters requires to drop down to the string syntax and forgo type-safety. This proposal supports this special case without introducing new syntax, but by introducing new overloads to the #selector compiler expression.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-property-selectors#proposed-solution>Proposed solution
> 
> Introduce two new overrides to the #selector expression that allows building a selector which points to the getter or the setter of a property.
> 
> class Person: NSObject {
>   dynamic var firstName: String
>   dynamic let lastName: String
>   dynamic var fullName: String {
>       return "\(firstName) \(lastName)"
>   }
> 
>   init(firstName: String, lastName: String) {
>     self.firstName = firstName
>     self.lastName = lastName
>   }
> }
> 
> let firstNameGetter = #selector(getter: Person.firstName)
> let firstNameSetter = #selector(setter: Person.firstName)
> Both overrides expect a property and the setter requires a variable property. For example, the following line of code would produce an error because the lastName property is defined with let.
> 
> let lastNameSetter = #selector(setter: Person.lastName)
> // Argument of #selector(setter:) must refer to a variable property
>  <https://github.com/hartbit/swift-evolution/tree/objc-property-selectors#impact-on-existing-code>Impact on existing code
> 
> The introduction of the new #selector overrides has no impact on existing code and could improve the string-literal-as-selector to #selector migrator.
> 
>  <https://github.com/hartbit/swift-evolution/tree/objc-property-selectors#alternatives-considered>Alternatives considered
> 
> A long term alternive could arrise from the design of lenses in Swift. But as this is purely hypothetical and out of scope for Swift 3, this proposal fixes the need for referencing property selectors in a type-safe way straight-away.
> 
> 
> _______________________________________________
> 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/20160224/91550793/attachment.html>


More information about the swift-evolution mailing list