[swift-evolution] Fwd: Re: Smart KeyPaths

[Matthew Johnson]

> On Mar 20, 2017, at 12:37 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 20.03.2017 17:56, Charles Srstka via swift-evolution wrote:
>>> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution
>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>>> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution
>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>> 
>>>> 
>>>> 
>>>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution
>>>>> <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>>>> 
>>>>> +1.  This is my favorite solution so far.
>>>>> 
>>>>> With ‘Person.keypath.name' it is obvious that we are creating a key
>>>>> path.  There is no ambiguity for the reader.  With autocomplete it will
>>>>> be very little extra typing anyway…
>>>> 
>>>> But that adds a lot of verbosity. They disregarded #keyPath because it
>>>> was too verbose.
>>> 
>>> The syntax in the original proposal is terse and elegant, and will
>>> probably be fine when a developer who is experienced with Swift and a
>>> particular codebase is first writing the code. Using “key path” or
>>> “keypaths” of perhaps a shorter term or even a single leading character
>>> (`#` ?) will make this feature more discoverable, tool-friendly and its
>>> usages more maintainable.
>>> 
>>> An extra term or character does add verbosity. How much is subjective,
>>> but I would not call it “a lot”. It does not add any nesting or code
>>> complexity. KVO code is usually a small fraction of most Objective-C
>>> projects (in my experience, at least) and it is probably safe to assume
>>> that the usage of this feature in Swift will be similar.
>>> 
>>> Verbosity vs clarity is often a tradeoff and I think that on balance, for
>>> a feature like this a little extra verbosity is worth it. Swift does not
>>> have the most terse syntax possible. `++` was removed, for example.
>>> 
>>> Just because an assignment is already implicitly typed in Swift does not
>>> mean that the ambiguity has to keep increasing without end for
>>> implementation of all new features, especially for ones that are not used
>>> very frequently.
>> 
>> +1 to all of this.
>> 
>> Particularly the point that KVO code typically is a small portion of the
>> overall code; this not only makes the added verbosity not that
>> egregious—certainly less so than “try” or “override”—but it also
>> underscores the fact that as a relatively uncommon feature, it’s not what a
>> reader of the code is going to be expecting to see. This latter point is
>> why I feel that without some kind of additional syntax—even if it’s just
>> one character—key paths will frequently get mistaken for property accesses
>> if they are implemented this way.
> 
> +1 from me. The problem is not that we shouldn't have instance props with the same name as class/static props. The problem is when you are *reading* some code(not always in IDE) it is hard to say what MyType.someprop[atIndex].name means. Is it static/class property or is it KeyPath? You just don't know - you have to check this in MyType declaration for any static property you don't know for sure it is static .
> 
> The same is for instance:
> 
> struct S {
> 	var index = 0
> 	func foo() {}
> 	subscript (at: Int) -> Int {return at*100}
> }
> //....
> let s = S()
> let value = s[index]
> // is it key path or subscript with `index` as parameter?
> 
> The difference with unbound methods(I hope I correctly understand that unbound method is `T.method` as mentioned by the proposal) is that unbound method IMO don't have *such* level of confusing. It can't have subscripts, it can't contains more than one part(the method name itself).

Yes, this is a difference that matters in some respects.

> 
> Also, using the above code,
> let method = S.foo
> 
> this line *has* a marker, that here we have an unbound method : there is *no* `()` after the foo. Do we have any such 'marker' in proposed key paths? No.
> 
> So I do believe this special feature(I mean it will be used rarely and reader most likely will not expect it in the code) requires a special syntax highlighting.
> 
> FWIW, currently I do like 3 proposed syntax to highlight what is happening here and also is not verbose like #keyPath():
> 
> 1. Type:path and instance:path
> 
> 2. Type at path and instance at path - as it reads nice "type at path" and "instance at path"
> 
> 3. And also I think as soon as we have `#` as marker for 'compiler magic', IMO it will be logically use it for the feature:
> Type#path and instance#path.

Hmm, I could live with this approach (#) as long as the dot shorthand still worked in type contexts expecting a key path with a concrete Root.

> 
> 
>> 
>> Charles
>> 
>> 
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
>> 
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution