>> On Dec 27, 2015, at 10:37 AM, Joe Groff <jgr...@apple.com> wrote: >> >> >> On Dec 26, 2015, at 11:22 PM, Douglas Gregor via swift-evolution >> <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 >> >> the proposal follows, and is available here as well: >> >> >> https://github.com/DougGregor/swift-evolution/blob/generalized-naming/proposals/0000-generalized-naming.md >> >> Comments appreciated! >> >> Generalized Naming for Any Function >> [snip] > >> 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]) -> () > At least as far as pure Swift is concerned, for unapplied access, like > `UIButton.currentTitle`, I think it would be more consistent with the way > method references works for that to give you the getter (or lens) without > decoration. instance.instanceMethod has type Args -> Ret, and > Type.instanceMethod has type Self -> Args -> Ret; by analogy, since > instance.instanceProperty has type Ret or inout Ret, it's reasonable to > expect Type.instanceProperty to have type Self -> [inout] Ret.
Yes, that seems reasonable. > Forming a getter or setter partially applied to an instance feels unmotivated > to me—{ button.currentTitle } or { button.currentTitle = $0 } already work, > and are arguably clearer than this syntax. I’m not strongly motivated by it in and of itself; rather, I like the idea of being able to get at all of the functions (for completeness/consistency), partly because of the Objective-C selector issue. > I acknowledge that this leaves forming selectors from setters out to dry, but > I feel like that's something that could be incorporated into a "lens" design > along with typed selectors. As a rough sketch, we could say that the > representation of @convention(selector) T -> inout U is a pair of > getter/setter selectors, I should weigh in over on a typed-selectors thread, but my personal view is that typed selectors are a well-designed feature that isn't worth doing: one would probably not use them outside of interoperability with Objective-C. To make that work, we'd need a Clang feature as well (to express the types), then all of the relevant Objective-C APIs would need to adopt it for us to see the benefits. On iOS, we are talking about a relatively small number of APIs (100-ish), and many of those have blocks/closure-based variants that are preferred. > and provide API on Selector to grab the individual selectors from that, maybe > Selector(getterFor: UIView.currentTitle)/(setterFor: UIView.currentTitle) Sure. I suspect that retrieving the selector of a getter/setter will be fairly rare, so I'm fine with that operation being ugly. > . I don't think get/set is a good interface for working with Swift > properties, so I don't like the idea of building in language support to > codify it beyond what's needed for ObjC interaction. That is an excellent point. I think you've convinced me to drop the getter/setter part of this: lenses are the right abstraction for working with properties, and we can handle ObjC getter/setter in some other way. >> 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? > From what I remember, the bigger concern with allowing foo(bar:bas:) without > backticks is parser error recovery. The unambiguity with call syntax depends > on having the `:)` token pair at the end. The edit distance between > foo(bar:bas:) and a call foo(bar: bas) or work-in-progress call foo(bar: x, > bas: ) is pretty slight, and would be tricky to give good diagnostics for. If > we felt confident we could give good diagnostics, I'd support removing the > backticks. > > -Joe
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution