> 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

Reply via email to