> 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. > 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
