> On Dec 27, 2015, at 10:37 AM, Joe Groff via swift-evolution
> <[email protected]> wrote:
>> 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. 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 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, and provide API on Selector to grab the individual
> selectors from that, maybe Selector(getterFor:
> UIView.currentTitle)/(setterFor: UIView.currentTitle). 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.
I know this might be too early, but: what syntax are we thinking of for lenses?
We might want to design this with future consistency in mind.
John.
>> 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
> [email protected] <mailto:[email protected]>
> https://lists.swift.org/mailman/listinfo/swift-evolution
> <https://lists.swift.org/mailman/listinfo/swift-evolution>
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
