<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Dec 3, 2017, at 5:40 PM, Chris Lattner <<a href="mailto:clattner@nondot.org" class="">clattner@nondot.org</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Dec 3, 2017, at 3:39 PM, Matthew Johnson <<a href="mailto:matthew@anandabits.com" class="">matthew@anandabits.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="Singleton" style="word-wrap: break-word; -webkit-nbsp-mode: space; 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="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"><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="">FWIW, another thought along these lines which would go even further in addressing my concerns would be to isolate PyVal and other dynamic types provided as part of Swift itself in a separate module which must be imported and linked against. That would give teams an easy way to opt-out of these types being available in their code base in a centralized fashion. </div></div></div></div></blockquote></div><br class=""><div class="">Matthew,</div><div class=""><br class=""></div><div class="">We have already had many directly analogous discussions, e.g. people who want to forbid the force-unwrap operator and IUOs. The conclusion, which has worked well enough in the community for multiple years now, is to relegate these kinds of coding standard to third party linter tools.</div></div></div></blockquote><div><br class=""></div><div>I view interoperability with dynamic languages as being independent of the core language so I don’t see that precedent as being <i class="">necessarily</i> applicable here. Interoperability with C is entirely different because it is the lingua franca of interoperability in general and predominant operating systems specifically. Further, force-unwrap and IUO are core parts of the language and not a library feature that could be provided in a separate module. One could reasonably ask what makes dynamic language interoperability more central to the language than the facilities provided by Foundation? We have to draw the line for the standard library somewhere and it isn’t as obvious to me as it sounds like it is to you that dynamic language interoperability should ship as part of the standard library.</div><div><br class=""></div><div>That said, I don’t feel so strongly about this to debate it further. It was just another suggestion that I thought might be palatable to you. Apparently I was wrong. :)</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></div></div></blockquote></div><br class=""></body></html>