> 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. > > 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. > > >> >>> Thanks, >>> Jon >>> >>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution >>>> <[email protected]> wrote: >>>> >>>> Key paths of this form: >>>> >>>> Person.name >>>> >>>> will always make it harder than necessary to: >>>> >>>> * search for all places where we are using key paths >>>> >>>> * do efficient code completion. Eg you’ll get a mix of static properties >>>> and key paths >>>> >>>> >>>> We’ve been using this kind of setup in our projects for some time now: >>>> >>>> class Person { >>>> >>>> struct keypath { >>>> >>>> static let name = #keyPath(Person.name) >>>> … >>>> } >>>> >>>> … >>>> } >>>> >>>> where a keypath is then used like this: >>>> >>>> Person.keypath.name >>>> >>>> and this has worked very well. It makes it easy to see where we are using >>>> a keypath rather than accessing some static property, it works very nicely >>>> with code completion and it makes it very easy to search for all places >>>> where we are using key paths from the Person type. >>>> >>>> I would prefer that the proposed keypath model would automatically >>>> organize key paths like this. >>>> >>>> >>>> Regards, >>>> >>>> Dietmar Planitzer >>>> >>>> >>>>> On Mar 19, 2017, at 20:49, Matthew Johnson via swift-evolution >>>>> <[email protected]> wrote: >>>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>> I think the clarity desired is more similar to that obtained by the >>>>>> `try` keyword. Ya, the compiler knows that this function throws already, >>>>>> but Swift aims for clarity in the source code. Clarity is often achieved >>>>>> by providing potentially redundant information for the programmer. >>>>>> >>>>>> As proposed, it is difficult to distinguish a key path from a static >>>>>> variable. Maybe that's not problematic? Well, it's up to the community >>>>>> to decide. >>>>> >>>>> Why don't we just say all instance properties are shadowed by a static >>>>> constant property of the same name with the appropriate key path type. >>>>> This makes it not mysterious at all but instead very straightforward. We >>>>> could even say that static and class properties are shadowed by a key >>>>> path property on the meta type. >>>>> >>>>> >>>>>> I do think it is a bit worrisome that static variable access might cause >>>>>> side effects (or at least, might take a while to compute) but creating >>>>>> key paths should not, but that's a fringe case probably. >>>>>> >>>>>> On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution >>>>>> <[email protected]> wrote: >>>>>> >>>>>>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> This is true of many things. It is why IDEs make type information >>>>>>>>> readily available. >>>>>>>> >>>>>>>> Is clarity not a thing to be desired? >>>>>>> >>>>>>> Clarity is in the eye of the beholder. Here's one notion of clarity: >>>>>>> >>>>>>> sum :: (Num a, Foldable t) => t a -> a >>>>>>> sum = foldl (+) 0 >>>>>>> >>>>>>> Here's another: >>>>>>> >>>>>>> int sum(int array[], size_t len) { >>>>>>> int total = 0; >>>>>>> for(size_t i = 0; i < len; i++) { >>>>>>> total += array[i]; >>>>>>> } >>>>>>> return total; >>>>>>> } >>>>>>> >>>>>>> And another: >>>>>>> >>>>>>> SUM PROC >>>>>>> ; this procedure will calculate the sum of an array >>>>>>> ; input : SI=offset address of the array >>>>>>> ; : BX=size of the array >>>>>>> ; output : AX=sum of the array >>>>>>> >>>>>>> PUSH CX ; push CX onto the STACK >>>>>>> PUSH DX ; push DX onto the STACK >>>>>>> >>>>>>> XOR AX, AX ; clear AX >>>>>>> XOR DX, DX ; clear DX >>>>>>> MOV CX, BX ; set CX=BX >>>>>>> >>>>>>> @SUM: ; loop label >>>>>>> MOV DL, [SI] ; set DL=[SI] >>>>>>> ADD AX, DX ; set AX=AX+DX >>>>>>> INC SI ; set SI=SI+1 >>>>>>> LOOP @SUM ; jump to label @SUM while CX!=0 >>>>>>> >>>>>>> POP DX ; pop a value from STACK into DX >>>>>>> POP CX ; pop a value from STACK into CX >>>>>>> >>>>>>> RET ; return control to the calling >>>>>>> procedure >>>>>>> SUM ENDP >>>>>>> >>>>>>> >>>>>>> And one more: >>>>>>> >>>>>>> extension Sequence where Element: Arithmetic { >>>>>>> func sum() { >>>>>>> return reduce(0, +) >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> Clarity is not achieved by explicitly stating every detail of your >>>>>>> code. It's achieved by explicitly stating what needs to be said, and >>>>>>> *not* explicitly stating what *doesn't* need to be said. >>>>>>> >>>>>>> The people who oppose using a special syntax for this feature think >>>>>>> that, by and large, clarity is best served by *not* explicitly stating >>>>>>> when you're using a key path. They believe that you are unlikely to run >>>>>>> into ambiguity and, when you do, it will be easy to work around it. >>>>>>> This is an opinion, so it's open to disagreement, but that's where they >>>>>>> stand on it. >>>>>>> >>>>>>> -- >>>>>>> Brent Royal-Gordon >>>>>>> Architechies >>>>>>> >>>>>>> _______________________________________________ >>>>>>> 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 >>> >>> _______________________________________________ >>> 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
