> On Dec 3, 2017, at 5:40 PM, Chris Lattner <clatt...@nondot.org> wrote: > > > >> On Dec 3, 2017, at 3:39 PM, Matthew Johnson <matt...@anandabits.com >> <mailto: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.
I view interoperability with dynamic languages as being independent of the core language so I don’t see that precedent as being necessarily 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. 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. :) > > -Chris >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
