> On Dec 3, 2017, at 5:38 PM, Chris Lattner <clatt...@nondot.org> wrote: > > > >> On Dec 3, 2017, at 3:34 PM, Matthew Johnson <matt...@anandabits.com >> <mailto: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.
Understood, and the goal of attracting them is a worthy one! > > -Chris >
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
