<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div><br><br>Sent from my iPad</div><div><br>On Mar 19, 2017, at 11:02 PM, <a href="mailto:jaden.geller@gmail.com">jaden.geller@gmail.com</a> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>You mean overloaded, not shadowed, right?</div></div></blockquote><div><br></div><div>No. What I mean by shadowed is this:</div><div><br></div><div>struct Foo {</div><div> // you write this:</div><div> let bar: Int</div><div> </div><div> // compiler automatically synthesizes a static keypath:</div><div> static let bar: KeyPath<Foo, Int></div><div>}</div><div><br></div><div>Shadowed was perhaps a bad word to use. :)</div><br><blockquote type="cite"><div><div><br>On Mar 19, 2017, at 8:49 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com">matthew@anandabits.com</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><br>Sent from my iPad</div><div><br>On Mar 19, 2017, at 10:31 PM, Jaden Geller via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="content-type" content="text/html; charset=utf-8"><div></div><div>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.</div><div><br></div><div>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. </div></div></blockquote><div><br></div><div><span style="background-color: rgba(255, 255, 255, 0);">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.</span></div><div><br></div><br><blockquote type="cite"><div><div>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.</div></div></blockquote><blockquote type="cite"><div><div><br>On Mar 19, 2017, at 6:32 PM, Brent Royal-Gordon via swift-evolution <<a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a>> wrote:<br><br></div><blockquote type="cite"><div><meta http-equiv="Content-Type" content="text/html charset=us-ascii"><div><blockquote type="cite" class=""><div class="">On Mar 19, 2017, at 4:47 PM, Charles Srstka <<a href="mailto:cocoadev@charlessoft.com" class="">cocoadev@charlessoft.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"><div class=""><blockquote type="cite" class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-stroke-width: 0px;">This is true of many things. It is why IDEs make type information readily available.</div></div></blockquote></div><br class=""><div class="">Is clarity not a thing to be desired?</div></div></div></blockquote><br class=""></div><div>Clarity is in the eye of the beholder. Here's one notion of clarity:</div><div><br class=""></div><div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span style="white-space: pre-wrap;" class="">sum :: (Num a, Foldable t) => t a -> a</span></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span><span style="white-space: pre-wrap;" class="">sum = foldl (+) 0</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div></div><div>Here's another:</div><div><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space: pre;"> </span>int sum(int array[], size_t len) {</div><div class=""><div><span class="Apple-tab-span" style="white-space: pre;"> </span>int total = 0;</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>for(size_t i = 0; i < len; i++) {</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>total += array[i];</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>return total;</div><div><span class="Apple-tab-span" style="white-space: pre;"> </span>}</div><div><br class=""></div><div></div></div><div class=""><span style="white-space: pre-wrap;" class="">And another:</span></div><div class=""><span style="white-space: pre-wrap;" class=""><br class=""></span></div><div class=""><span style="white-space: pre-wrap;" class=""> 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</span></div><div class=""><br class=""></div><div class="">And one more:</div><div class=""><br class=""></div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>extension Sequence where Element: Arithmetic {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>func sum() {</div><div class=""><span class="Apple-tab-span" style="white-space:pre"> </span>return <span style="white-space: pre-wrap;" class="">reduce(0, +)</span></div><div class=""><span style="white-space: pre-wrap;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div class=""><span style="white-space: pre-wrap;" class=""><span class="Apple-tab-span" style="white-space:pre"> </span>}</span></div><div class=""><br class=""></div><div class="">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.</div><div class=""><br class=""></div><div class="">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.</div><br class=""><div class="">
<span class="Apple-style-span" style="border-collapse: separate; font-variant-ligatures: normal; font-variant-position: normal; font-variant-numeric: normal; font-variant-alternates: normal; font-variant-east-asian: normal; line-height: normal; border-spacing: 0px;"><div class=""><div style="font-size: 12px; " class="">-- </div><div style="font-size: 12px; " class="">Brent Royal-Gordon</div><div style="font-size: 12px; " class="">Architechies</div></div></span>
</div>
<br class=""></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote><blockquote type="cite"><div><span>_______________________________________________</span><br><span>swift-evolution mailing list</span><br><span><a href="mailto:swift-evolution@swift.org">swift-evolution@swift.org</a></span><br><span><a href="https://lists.swift.org/mailman/listinfo/swift-evolution">https://lists.swift.org/mailman/listinfo/swift-evolution</a></span><br></div></blockquote></div></blockquote></div></blockquote></body></html>