[swift-evolution] Smart KeyPaths

jaden.geller at gmail.com jaden.geller at gmail.com
Sun Mar 19 22:31:45 CDT 2017


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. 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 at swift.org> wrote:
> 
>>> On Mar 19, 2017, at 4:47 PM, Charles Srstka <cocoadev at 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 at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170319/b01c1bec/attachment-0001.html>


More information about the swift-evolution mailing list