Currently, they can be disambiguated using (self as ProtocolA).bar(), no? Félix
> Le 29 déc. 2015 à 14:10:51, Erica Sadun via swift-evolution > <swift-evolution@swift.org> a écrit : > > Talk about things you didn't know you needed until you see them. This is a > really nice way of disambiguating! > > -- E > >> On Dec 29, 2015, at 12:03 PM, Douglas Gregor via swift-evolution >> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >> >> >> >> Sent from my iPhone >> >> On Dec 29, 2015, at 10:17 AM, Joe Groff <jgr...@apple.com >> <mailto:jgr...@apple.com>> wrote: >> >>> We also have a problem with disambiguating same-named members that come >>> from different extensions, whether via protocol extensions or independent >>> concrete extensions from different modules. Could we extend this scheme to >>> allow for disambiguating extension methods by protocol/module name? >> >> That's a fantastic idea! >> >>> >>> extension ProtocolA { func foo() } >>> extension ProtocolB { func foo() } >>> >>> public struct Foo: ProtocolA, ProtocolB { >>> func callBothFoos() { >>> self.`ProtocolA.foo`() >>> self.`ProtocolB.foo`() >>> } >>> } >>> >>> import A // extends Bar with bar() >>> import B // also extends Bar with bar() >>> >>> extension Bar { >>> func callBothBars() { >>> self.`A.bar`() >>> self.`B.bar`() >>> } >>> } >>> >>> -Joe >>> >>>> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution >>>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote: >>>> >>>> Hi all, >>>> >>>> Here’s a proposal draft to allow one to name any function in Swift. In >>>> effect, it’s continuing the discussion of retrieving getters and setters >>>> as functions started by Michael Henson here: >>>> >>>> >>>> https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html >>>> >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html> >>>> >>>> the proposal follows, and is available here as well: >>>> >>>> >>>> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md> >>>> >>>> Comments appreciated! >>>> >>>> Generalized Naming for Any Function >>>> >>>> Proposal: SE-NNNN >>>> <https://github.com/apple/swift-evolution/blob/master/proposals/0000-generalized-naming.md> >>>> Author(s): Doug Gregor <https://github.com/DougGregor> >>>> Status: Awaiting Review >>>> Review manager: TBD >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#introduction>Introduction >>>> >>>> Swift includes support for first-class functions, such that any function >>>> (or method) can be placed into a value of function type. However, it is >>>> not possible to specifically name every function that is part of a Swift >>>> program---one cannot provide the argument labels when naming a function, >>>> nor are property and subscript getters and setters referenceable. This >>>> proposal introduces a general syntax that allows one to name anything that >>>> is a function within Swift in an extensible manner. >>>> >>>> Swift-evolution thread: Michael Henson started a thread about the >>>> getter/setter issue here >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html>, >>>> continued here >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002203.html>. >>>> See the Alternatives considered >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#alternatives-considered> >>>> section for commentary on that discussion. >>>> >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#motivation>Motivation >>>> >>>> It's fairly common in Swift for multiple functions or methods to have the >>>> same "base name", but be distinguished by parameter labels. For example, >>>> UIView has three methods with the same base name insertSubview: >>>> >>>> extension UIView { >>>> func insertSubview(view: UIView, at index: Int) >>>> func insertSubview(view: UIView, aboveSubview siblingSubview: UIView) >>>> func insertSubview(view: UIView, belowSubview siblingSubview: UIView) >>>> } >>>> When calling these methods, the argument labels distinguish the different >>>> methods, e.g., >>>> >>>> someView.insertSubview(view, at: 3) >>>> someView.insertSubview(view, aboveSubview: otherView) >>>> someView.insertSubview(view, belowSubview: otherView) >>>> However, when referencing the function to create a function value, one >>>> cannot provide the labels: >>>> >>>> let fn = someView.insertSubview // ambiguous: could be any of the three >>>> methods >>>> In some cases, it is possible to use type annotations to disambiguate: >>>> >>>> let fn: (UIView, Int) = someView.insertSubview // ok: uses >>>> insertSubview(_:at:) >>>> let fn: (UIView, UIView) = someView.insertSubview // error: still >>>> ambiguous! >>>> To resolve the latter case, one must fall back to creating a closure: >>>> >>>> let fn: (UIView, UIView) = { view, otherView in >>>> button.insertSubview(view, otherView) >>>> } >>>> which is painfully tedious. A similar workaround is required to produce a >>>> function value for a getter of a property, e.g., >>>> >>>> extension UIButton { >>>> var currentTitle: String? { ... } >>>> } >>>> >>>> var fn: () -> String? = { () in >>>> return button.currentTitle >>>> } >>>> One additional bit of motivation: Swift should probably get some way to >>>> ask for the Objective-C selector for a given method (rather than writing a >>>> string literal). The argument to such an operation would likely be a >>>> reference to a method, which would benefit from being able to name any >>>> method, including getters and setters. >>>> >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#proposed-solution>Proposed >>>> solution >>>> >>>> Swift currently has a back-tick escaping syntax that lets one use keywords >>>> for names, which would otherwise fail to parse. For example, >>>> >>>> func `try`() -> Bool { ... } >>>> declares a function named try, even though try is a keyword. I propose to >>>> extend the back-tick syntax to allow compound Swift names (e.g., >>>> insertSubview(_:aboveSubview:)) and references to the accessors of >>>> properties (e.g., the getter for currentTitle). Specifically, >>>> >>>> Compound names can be written entirely within the back-ticks, e.g., >>>> >>>> let fn = someView.`insertSubview(_:at:)` >>>> let fn1 = someView.`insertSubview(_:aboveSubview:)` >>>> The same syntax can also refer to initializers, e.g., >>>> >>>> let buttonFactory = UIButton.`init(type:)` >>>> Getters and setters can be written using dotted syntax within the >>>> back-ticks: >>>> >>>> let specificTitle = button.`currentTitle.get` // has type () -> String? >>>> let otherTitle = UIButton.`currentTitle.get` // has type (UIButton) -> () >>>> -> String? >>>> let setTintColor = button.`tintColor.set` // has type (UIColor!) -> () >>>> The same syntax works with subscript getters and setters as well, using >>>> the full name of the subscript: >>>> >>>> extension Matrix { >>>> subscript (row row: Int) -> [Double] { >>>> get { ... } >>>> set { ... } >>>> } >>>> } >>>> >>>> let getRow = someMatrix.`subscript(row:).get` // has type (Int) -> () -> >>>> [Double] >>>> let setRow = someMatrix.`subscript(row:).set` // has type (Int) -> >>>> ([Double]) -> () >>>> If we introduce property behaviors into Swift, the back-tick syntax could >>>> also be used to refer to behaviors, e.g., accessing the lazy behavior of a >>>> property: >>>> >>>> self.`myProperty.lazy`.clear() >>>> Base names that are meaningful keywords (init and subscript) can be >>>> escaped with a nested pair of back-ticks: >>>> >>>> extension Font { >>>> func `subscript`() -> Font { >>>> // return the subscript version of the given font >>>> } >>>> } >>>> >>>> let getSubscript = font.``subscript`()` // has type () -> Font >>>> The "produce the Objective-C selector for the given method" operation will >>>> be the subject of a separate proposal. However, here is one possibility >>>> that illustrations how it uses the proposed syntax here: >>>> >>>> let getter: Selector = objc_selector(NSDictionary.`subscript(_:).get`) // >>>> produces objectForKeyedSubscript: >>>> let setter: Selector = objc_selector(NSDictionary.`subscript(_:).set`) // >>>> produces setObject:forKeyedSubscript: >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#impact-on-existing-code>Impact >>>> on existing code >>>> >>>> This is a purely additive feature that has no impact on existing code. The >>>> syntactic space it uses is already present, and it merely extends the use >>>> of back-ticks from storing a single identifier to more complex names. >>>> >>>> >>>> <https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md#alternatives-considered>Alternatives >>>> considered >>>> >>>> Michael Henson proposed >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151207/002168.html> >>>> naming getters and setters using # syntax followed by get or set, e.g., >>>> >>>> let specificTitle = button.currentTitle#get >>>> The use of postfix # is a reasonable alternative here, and more >>>> lightweight than two back-ticks for the simple getter/setter case. The >>>> notion could be extended to allow argument labels for functions, discussed >>>> here >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/002210.html>. >>>> The proposals in that discussion actually included type annotations as >>>> well, but the syntax seems cleaner---and more directly focused on >>>> names---without them, e.g.,: >>>> >>>> let fn = someView.insertSubview#(_:at:) >>>> which works. I didn't go with this syntax because (1) it breaks up Swift >>>> method names such as insertSubview(_:at:)with an # in the middle, and (2) >>>> while useful, this feature doesn't seem important enough to justify >>>> overloading #further. >>>> >>>> Joe Groff notes >>>> <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20151214/003008.html> >>>> that lenses are a better solution than manually retrieving getter/setter >>>> functions when the intent is to actually operate on the properties. That >>>> weakens the case this proposal makes for making getters/setters available >>>> as functions. However, it doesn't address the general naming issue or the >>>> desire to retrieve the Objective-C selector for a getter/setter. >>>> >>>> Can we drop the back-ticks? It's very tempting to want to drop the >>>> back-ticks entirely, because something like >>>> >>>> let fn = someView.insertSubview(_:at:) >>>> can be correctly parsed as a reference to insertSubview(_:at:). However, >>>> it breaks down at the margins, e.g., with getter/setter references or >>>> no-argument functions: >>>> >>>> extension Optional { >>>> func get() -> T { return self! } >>>> } >>>> >>>> let fn1 = button.currentTitle.get // getter or Optional<String>.get? >>>> let fn2 = set.removeAllElements() // call or reference? >>>> >>>> >>>> - Doug >>>> >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org <mailto:swift-evolution@swift.org> >> https://lists.swift.org/mailman/listinfo/swift-evolution >> <https://lists.swift.org/mailman/listinfo/swift-evolution> > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org <mailto:swift-evolution@swift.org> > https://lists.swift.org/mailman/listinfo/swift-evolution > <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
