[swift-evolution] Disallow arbitrary expressions in selectors

[Thorsten Seitz]

Looks good to me!

-Thorsten 

> Am 28.04.2016 um 16:56 schrieb Alex Hoppen via swift-evolution <swift-evolution at swift.org>:
> 
> During the implementation of SE-0064 (Referencing Objective-C selector of property getters and setters) I have come across an issue that could be resolved my a minor change to the language and simplify the compiler a lot. I have drafted a proposal below.
> 
> Thoughts, comments, especially objections, appreciated.
> 
> – Alex
> 
> GitHub-Link: https://github.com/ahoppen/swift-evolution/blob/arbitrary-expressions-in-selectors/proposals/0000-arbitrary-expressions-in-selectors.md
> 
> Disallow arbitrary expressions in selectors
> Proposal: SE-NNNN
> Author(s): Alex Hoppen
> Status: Draft
> Review manager: TBD
> Introduction
> 
> It is currently possible to write arbitrary expressions inside #selector like the following: #selector(callThisFunc().bar). This complicates the implementation of proposals SE-0064 (Referencing Objective-C selector of property getters and setters) and SE-0062 (Referencing Objective-C key-paths) a lot. 
> 
> This proposal restricts expressions inside selectors to be a sequence of property or method refernces. I believe this will not be a major restrictions since arbitrary expressions in selectors are probably rarely used, have some rough edges and removing them would simplify the compiler.
> 
> Proposed solution
> 
> I propose allowed expressions inside #selector (and once implemented #keyPath) to be a series of instance or class members separated by . and allow disambiguating the last component using as.
> 
> Detailed design
> 
> Examples
> 
> class Address: NSObject {
>   dynamic var street: String
>   dynamic var town: String
> 
>   init(street: String, town: String) {
>     self.street = street
>     self.town = town
>   }
> }
> 
> class Person: NSObject {
>   dynamic var name: String
>   dynamic var homeAddress: Address
> 
>   func workAddress() -> Address {
>     // ...
>   }
> 
>   func workAddress(formatter: AddressFormatter) -> String {
>     // ...
>   }
> 
>   init(name: String, homeAddress: Address) {
>     self.name = name
>     self.homeAddress = homeAddress
>   }
> }
> 
> let me: Person = ...
> The following examples will continue to work:
> 
> let _ = #selector(getter: Person.name)
> let _ = #selector(getter: me.name)
> 
> let _ = #selector(getter: Person.homeAddress.street)
> // Could also be written as
> let _ = #selector(getter: Address.street)
> 
> let _ = #selector(Person.workAddress as () -> Address)
> let _ = #selector(Person.workAddress(formatter: ))
> I propose removing this kind of selector:
> 
> // Should produce selector "street". Note that the method workAddress() is never 
> // called and its return type only used during type checking
> let _ = #selector(getter: me.workAddress().street) 
> 
> // The above can be rewritten in a cleaner way like the following
> let _ = #selector(getter: Address.street)
> The proposed way to rewrite the selector elimininates potential confusion about the fact that calling a method inside #selector actually doesn't invoke it.
> 
> Grammar
> 
> selector → #selector(selector-modiferopt selector-path)
> 
> selector-modifier → getter:
> selector-modifier → setter:
> 
> selector-path → type-identifier . selector-member-path as-disambiguationopt
> selector-path → selector-member-path as-disambiguationopt
> 
> selector-member-path → identifier
> selector-member-path → unqualified-name
> selector-member-path → identifier . selector-member-path
> 
> as-disambiguation → as type-identifier
> For a further rationale on why arbitrary expressions are no longer possible, see the discussion on bugs.swift.org.
> 
> Impact on existing code
> 
> Code that currently uses this feature needs to be rewritten as described in the example above. I believe, however, that the feature is rarely used so it will affect only very little source code and where it is currently used the proposed update is actually more readable.
> 
> Alternatives considered
> 
> The only alternative I see is trying to keep the current semantics and implement them for the getter:/setter: selectors.
> 
> 
> _______________________________________________
> 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/20160429/c22eea4e/attachment.html>