Looks good to me! -Thorsten
> Am 28.04.2016 um 16:56 schrieb Alex Hoppen via swift-evolution > <[email protected]>: > > 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 > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
