Sent from my iPad
On Mar 20, 2017, at 6:18 AM, Rien via swift-evolution <swift-evolution@swift.org> wrote: >> >> On 20 Mar 2017, at 12:12, David Hart via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >>> On 20 Mar 2017, at 10:39, Jonathan Hull via swift-evolution >>> <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. >> > > Then let me add a +1 for the verbose solution as well. > > Sometimes verbosity is not bad. Huge -1 from me. What we do should be consistent with unbound methods. This idea should need to justify why the inconsistency (or changing unbound methods - a breaking change) is worth the benefit you perceive. I think that's a pretty tough sell. If we did go with the verbose option I hope the dot shorthand that only requires a property name would still work in a type context expecting a key path with a concrete root type. > > Regards, > Rien > > Site: http://balancingrock.nl > Blog: http://swiftrien.blogspot.com > Github: http://github.com/Balancingrock > Project: http://swiftfire.nl > >>> Thanks, >>> Jon >>> >>>> On Mar 19, 2017, at 9:20 PM, Dietmar Planitzer via swift-evolution >>>> <swift-evolution@swift.org> 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 >>>>> <swift-evolution@swift.org> wrote: >>>>> >>>>> >>>>> >>>>> Sent from my iPad >>>>> >>>>>> On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution >>>>>> <swift-evolution@swift.org> 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 >>>>>> <swift-evolution@swift.org> wrote: >>>>>> >>>>>>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka <cocoa...@charlessoft.com> >>>>>>>> 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 >>>>>>> swift-evolution@swift.org >>>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>>> _______________________________________________ >>>>>> swift-evolution mailing list >>>>>> swift-evolution@swift.org >>>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>>> _______________________________________________ >>>>> swift-evolution mailing list >>>>> swift-evolution@swift.org >>>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>>> >>>> _______________________________________________ >>>> swift-evolution mailing list >>>> swift-evolution@swift.org >>>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> >>> _______________________________________________ >>> swift-evolution mailing list >>> swift-evolution@swift.org >>> https://lists.swift.org/mailman/listinfo/swift-evolution >> >> _______________________________________________ >> swift-evolution mailing list >> swift-evolution@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
