[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

[Gwendal Roué]

> Le 1 déc. 2017 à 00:54, Xiaodi Wu via swift-evolution <swift-evolution at 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é

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171201/56ee844f/attachment.html>