[swift-evolution] Smart KeyPaths

[Jean-Daniel]

> Le 20 mars 2017 à 15:52, Matthew Johnson via swift-evolution <swift-evolution at swift.org> a écrit :
> 
>> 
>> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>> 
>> 
>>> On Mar 20, 2017, at 5: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.
>> 
>> 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.
> 
> It also makes it inconsistent with how unbound methods behave.  I have yet to hear a convincing argument about why key paths should be treated different syntactically.

Because they are two different beasts. Are you arguing that we should allow unbound method as subscript parameter to be consistent with key path ?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170321/ba2f8feb/attachment.html>