> Le 1 déc. 2017 à 00:54, Xiaodi Wu via swift-evolution > <swift-evolution@swift.org> a écrit : > > As I wrote in the earlier thread, I think this is the wrong way to reason > about the use case--and a counterproductive one that effectively rejects the > legitimacy of dynamic language interop support instead of working towards an > optimal solution for it. Along those lines, some replies to your message > literally question whether the user case is worthwhile to support at all, > which I think entirely misses the mark. > > As Chris writes in his proposal, there are several areas (such as data > science) where, to put it plainly, Python or another dynamic language is > significantly better than Swift due to a much larger ecosystem of libraries, > tools, and user communities, with sometimes decades of lead time. It is > nonsensical to talk about how Swift is "supposed to be better" in any way > whatsoever in that context. As diehard Swift users, we may be confident that > the virtues of Swift's syntax, static typing, compiler smarts, protocol-based > design, or whatever else offer opportunities for, say, data science libraries > and tools to be better in the future, eventually. But to make this even > possible involves first making Swift a viable language in which to work with > current data science tools. Your top bullet point here reasons that one key > flaw of Chris's proposal is that he has not somehow figured out how to make > dynamic Python calls give compile-time Swift errors. If this is the minimum > bar for Python interop, then as far as I can tell, it seems isomorphic to > rejecting interop with dynamic languages altogether.
Hello, I agree with this reasoning. Unless I miss the point, I see C. Lattner's proposals, function calls and member lookup, as a very restricted interface to dynamic languages. They do not aim at embedding dynamic languages into Swift at all, and let users write long Python/Ruby/JS programs in Swift. For example, "real" python would need list comprehension, generators, async/await, etc. Such features are clearly out of scope of the proposals. We can thus expect serious programs that use those features to process in three steps: 1 turn Swift values in foreign values, 2. process foreign values with a restricted foreign API, 3. turn computed foreign values into Swift values. It's all about using good tools when needed. In this context, I too am concerned with retroactive conformance. If it were forbidden, it would make it very clear where the dynamic scope starts and ends: // Input let swiftInt: Int = 12 // Enter Python let pyInt = Python.Value(swiftInt) // Python code let pyResult = pyInt.someFunc() // Back to Swift if let swiftResult = Int(pyResult) { // proceed } Gwendal Roué
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution