+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…
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
