> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution 
> <swift-evolution@swift.org> wrote:
> 
>> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@swift.org>> wrote:
>> 
>> 
>> 
>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution 
>>> <swift-evolution@swift.org <mailto:swift-evolution@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.

Charles

_______________________________________________
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to