> On Dec 3, 2017, at 2:44 PM, Xiaodi Wu <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. >> 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
