> On Dec 3, 2017, at 3:34 PM, Matthew Johnson <matt...@anandabits.com> wrote: > >> >> On Dec 3, 2017, at 5:14 PM, Chris Lattner <clatt...@nondot.org >> <mailto: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. > > This would certainly address the majority of my concerns while still > addressing the motivating use case. I don’t think it’s an ideal solution but > it’s one I could live with and perhaps it is the best tradeoff. It would > certainly focus the proposal more directly on the use case you care most > about leaving the distraction of conformances by user-defined Swift types as > a separate conversation.
> If would had to choose an alternative is this preferable to you over some > kind of usage-site annotation? Yes, vastly. This does not completely defeat the purpose of the proposal in the first place. >>>> 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. > > On a technical level that is true in many respects, but on a social level > certainly not. You would obviously know a lot better than I, but I imagine > that Swift’s success at displacing Objective-C in the Apple world was not at > all a foregone conclusion in the earliest days. It is now a well established > language with a significant user base that isn’t going anywhere. Correct. Similarly, it is also not a forgone conclusion that the Python and Javascript communities will care. Python and Javascript have at least a couple orders of magnitude more programmers than Swift does. Swift is a toy by comparison. -Chris
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
