You mean overloaded, not shadowed, right?
> On Mar 19, 2017, at 8:49 PM, Matthew Johnson <matt...@anandabits.com> 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
