[swift-evolution] Smart KeyPaths

[Matthew Johnson]

Sent from my iPad

> On Mar 21, 2017, at 7:27 AM, Jean-Daniel <mailing at xenonium.com> wrote:
> 
> 
>>> 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 ?

Obviously not.  A keypath represents data so a subscript is the logical way to access the data.  An unbound method represents a function so you call it.  But both represent unbound ways to access members of instances of a type, store that access in a variable, pass it as an argument, etc.  

I think the language is best served if all unbound members are accessible using the same syntax.  IMO this proposal does the right thing by choosing consistency with existing language features.  The current syntax for unbound methods works and hasn't caused any confusions I'm aware of in practice.  

I don't feel too strongly about what syntax we use as long as it's concise and works for accessing all unbound members.  If people want to make the case for using `#` instead of `.` to do this I won't object but I won't be a vocal advocate either.  However, I think that should be an independent proposal if somebody wants to pursue it rather than a bike shed on this proposal which would only lead to inconsistency between key paths and unbound methods if it succeeds.

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