> On Dec 3, 2017, at 5:14 PM, Chris Lattner <clatt...@nondot.org> wrote: > > >> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu <xiaodi...@gmail.com >> <mailto:xiaodi...@gmail.com>> wrote: >> >>> >>> and you don’t realize that PyVal’s are involved. However, if you are >>> actively writing the code, you have access to code completion and other >>> things that tell you these types, and if it is important for the clarity of >>> the code, you write this instead: >>> >>> let x :PyVal = foo()[“someKey”] >>> >>> There is nothing specific to this proposal about this issue. >> >> See above. In the case of PyVal specifically the concern is somewhat >> mitigated by the name of the type. That won’t necessarily always be the >> case. >> >> 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. > >>> You miss my point. My point is that AnyObject lookup was carefully >>> considered, has stood the test of time, and is the *right* answer. Swift 1 >>> would not have been nearly as successful without it. >> >> I don’t think I do. I was trying to agree with exactly the point that it >> was the right answer in the early days of Swift and getting it right then >> was essential to Swift’s success. > > Ok, but the “early days of Swift” are directly analogous to the present days > of other dynamic languages. > >> >> Aside from the historical necessity of AnyObject, it is also a very specific >> and widely know type that doesn’t have any statically available members at >> all and only looks up @objc members. These properties help to reduce the >> risk that somebody misunderstands what is going on. >> >> I imagine we could restrict all such dynamic types from having any >> statically available members without losing much. > > This isn’t practical. We need some traditionally defined members so that > PyVal can conform to standard protocols, like ExpressibleByIntegerLiteral and > many others. > > -Chris >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
