<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: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 class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>