> 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.  


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.


swift-evolution mailing list

Reply via email to