> Le 20 mars 2017 à 15:52, Matthew Johnson via swift-evolution > <[email protected]> a écrit : > >> >> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution >> <[email protected]> wrote: >> >> >> >>> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >>> <[email protected]> wrote: >>> >>> >>> >>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>> <[email protected]> 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 ?
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
