> On Dec 3, 2017, at 3:39 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >>> 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. >> >> Right, this is specifically mentioned as option #2 in the proposal: >> https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse >> >> <https://gist.github.com/lattner/b016e1cf86c43732c8d82f90e5ae5438#reducing-potential-abuse> >> >> It sounds like Matthew’s concerns can be addressed by him +1’ing that >> alternative when it comes up for review. > > 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.
Matthew, 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. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
