If a character had to be used to denote key paths then I would prefer this one:
1. Type:path.to.value and instance:path.to.value I feel like the # screams at me. :-) > On Mar 20, 2017, at 1:52 PM, Matthew Johnson via swift-evolution > <[email protected]> wrote: > > >> On Mar 20, 2017, at 12:37 PM, Vladimir.S via swift-evolution >> <[email protected]> wrote: >> >> On 20.03.2017 17:56, Charles Srstka via swift-evolution wrote: >>>> On Mar 20, 2017, at 9:23 AM, Christopher Kornher via swift-evolution >>>> <[email protected] <mailto:[email protected]>> wrote: >>>> >>>>> On Mar 20, 2017, at 5:12 AM, David Hart via swift-evolution >>>>> <[email protected] <mailto:[email protected]>> wrote: >>>>> >>>>> >>>>> >>>>>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>>>>> <[email protected] <mailto:[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. >>>> >>>> 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. >> >> +1 from me. The problem is not that we shouldn't have instance props with >> the same name as class/static props. The problem is when you are *reading* >> some code(not always in IDE) it is hard to say what >> MyType.someprop[atIndex].name means. Is it static/class property or is it >> KeyPath? You just don't know - you have to check this in MyType declaration >> for any static property you don't know for sure it is static . >> >> The same is for instance: >> >> struct S { >> var index = 0 >> func foo() {} >> subscript (at: Int) -> Int {return at*100} >> } >> //.... >> let s = S() >> let value = s[index] >> // is it key path or subscript with `index` as parameter? >> >> The difference with unbound methods(I hope I correctly understand that >> unbound method is `T.method` as mentioned by the proposal) is that unbound >> method IMO don't have *such* level of confusing. It can't have subscripts, >> it can't contains more than one part(the method name itself). > > Yes, this is a difference that matters in some respects. > >> >> Also, using the above code, >> let method = S.foo >> >> this line *has* a marker, that here we have an unbound method : there is >> *no* `()` after the foo. Do we have any such 'marker' in proposed key paths? >> No. >> >> So I do believe this special feature(I mean it will be used rarely and >> reader most likely will not expect it in the code) requires a special syntax >> highlighting. >> >> FWIW, currently I do like 3 proposed syntax to highlight what is happening >> here and also is not verbose like #keyPath(): >> >> 1. Type:path and instance:path >> >> 2. Type@path and instance@path - as it reads nice "type at path" and >> "instance at path" >> >> 3. And also I think as soon as we have `#` as marker for 'compiler magic', >> IMO it will be logically use it for the feature: >> Type#path and instance#path. > > Hmm, I could live with this approach (#) as long as the dot shorthand still > worked in type contexts expecting a key path with a concrete Root. > >> >> >>> >>> Charles >>> >>> >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
