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

Reply via email to