> 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
