[swift-evolution] Smart KeyPaths

[Haravikk]

> On 21 Mar 2017, at 20:04, David Smith via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 
>> On Mar 20, 2017, at 4:12 AM, David Hart via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution <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.
> 
> For what it's worth, I'm not especially worried about verbosity. Long-term I'm hoping that this feature and the ones we build on it will see far broader use than keypaths ever did in ObjC, but a little more typing isn't that bad. What *is* a loss though, is something I'll call "conceptual surface area".
> 
> We talk a lot about "conceptual load" when designing APIs, which is the notion that even if each individual concept is simple, the sheer volume of things that you have to keep track of can be exhausting, make learning difficult, and cause mistakes. With some features though, the conceptual load comes more from what isn't there. With unbound methods, you have to know "ok String.init gets me String's initializer as an unbound function I can call, so I can do stuff like [1, 2, 3].map(String.init)" but you *also* have to know "but that doesn't work on subscripts or properties, just methods". So even though there's only one concept here, the hole in the feature is itself an additional concept; an irregularly shaped thing having more mental surface area.
> 
> So the biggest reason I like the current syntax proposal is that it fills in a hole, reducing the conceptual surface area to "ok, Foo.bar gets me an unbound version of anything".
> 
> Unfortunately, as everyone has pointed out, static/class properties make that claim not so true. Hanging keypaths off a ".keypath" class property also conflicts, since there's nothing stopping a method or property from being called "keypath". I see several paths forward from here, not least of which is "it's probably not a huge deal in practice", but I'd like to think about it and listen to the discussion a bit longer before suggesting anything.

Would an operator solve this issue? I have to admit I've never really used something like this so I've only really been half-glancing at this thread as the messages come up, but it seems like an operator would keep the paths from being too verbose, while disambiguating.

This may in fact be something where the dollar sign could be a good fit, i.e: $Foo.bar

It's unambiguous with shorthand variables in closures, and keeps the feature in the same kind of "sort of compiler magic" category that they exist in, since they're not proper variables, but can be used as such, just as a key-path here is sort of a property access, but handled in a special way.

Just a thought anyway.