> 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