<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div><br class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2017, at 3:34 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><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=""><br class="Apple-interchange-newline">On Dec 3, 2017, at 5:14 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="" style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2017, at 2:44 PM, Xiaodi Wu <<a href="mailto:xiaodi.wu@gmail.com" class="">xiaodi.wu@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><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; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><div class=""><div class="" style="word-wrap: break-word;"><div class=""><div class=""><br class="Apple-interchange-newline">and you don’t realize that PyVal’s are involved. However, if you are actively writing the code, you have access to code completion and other things that tell you these types, and if it is important for the clarity of the code, you write this instead:</div><div class=""><br class=""></div><div class=""><div class=""><span class="m_2215210071369923463Apple-tab-span" style="white-space: pre-wrap;"> </span>let x :PyVal = foo()[“someKey”]</div><div class=""><br class=""></div><div class="">There is nothing specific to this proposal about this issue.</div></div></div></div></div></blockquote><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;"><br class=""></div><div class="" style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;">See above. In the case of PyVal specifically the concern is somewhat mitigated by the name of the type. That won’t necessarily always be the case.</div></div></div></blockquote><div class=""><br class=""></div><div class="">If that's the concern, then it would be pretty straightforward to restrict dynamic protocols for stdlib internal use only and expose only PyVal. The trade-off is that all such bridging code would have to be shipped with Swift itself.</div></div></div></div></div></div></blockquote><div class=""><br class=""></div>Right, this is specifically mentioned as option #2 in the proposal:</div><div class=""><a href="https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse" class="">https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse</a></div><div class=""><br class=""></div><div class="">It sounds like Matthew’s concerns can be addressed by him +1’ing that alternative when it comes up for review.</div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">This would certainly address the majority of my concerns while still addressing the motivating use case. I don’t think it’s an ideal solution but it’s one I could live with and perhaps it is the best tradeoff. It would certainly focus the proposal more directly on the use case you care most about leaving the distraction of conformances by user-defined Swift types as a separate conversation.</div></div></blockquote><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">If would had to choose an alternative is this preferable to you over some kind of usage-site annotation?</div></div></blockquote><div><br class=""></div><div>Yes, vastly. This does not completely defeat the purpose of the proposal in the first place.</div><div><br class=""></div><div><br class=""></div><blockquote type="cite" class=""><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="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div class=""><blockquote type="cite" class=""><div class=""><div class="Singleton"><div dir="ltr" class=""><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex;"><div class="" style="word-wrap: break-word;"><div class=""><blockquote type="cite" class=""><div class=""><div class="" style="word-wrap: break-word;"><div class="">You miss my point. My point is that AnyObject lookup was carefully considered, has stood the test of time, and is the *right* answer. Swift 1 would not have been nearly as successful without it.</div></div></div></blockquote><div class=""><br class=""></div><div class="">I don’t think I do. I was trying to agree with exactly the point that it was the right answer in the early days of Swift and getting it right then was essential to Swift’s success. </div></div></div></blockquote></div></div></div></div></div></blockquote><div class=""><br class=""></div><div class="">Ok, but the “early days of Swift” are directly analogous to the present days of other dynamic languages.</div></div></div></div></blockquote><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class=""><br class=""></div><div style="font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px;" class="">On a technical level that is true in many respects, but on a social level certainly not. You would obviously know a lot better than I, but I imagine that Swift’s success at displacing Objective-C in the Apple world was not at all a foregone conclusion in the earliest days. It is now a well established language with a significant user base that isn’t going anywhere.</div></div></blockquote></div><br class=""><div class="">Correct. Similarly, it is also not a forgone conclusion that the Python and Javascript communities will care. Python and Javascript have at least a couple orders of magnitude more programmers than Swift does. Swift is a toy by comparison.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>