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

[Chris Lattner]

On Dec 5, 2017, at 11:51 PM, Jonathan Hull <jhull at gbis.com> wrote:
> Ok, I have changed my mind about the need for a marker, and will accept the proposal as-is.  I realized that these dynamic member lookup types can just be made inner types, and so I can easily create the .dynamic behavior in my own code if I want under the current proposal.  I also realized that requiring a marker would screw up the proxy use-case of this.
> 
> I do still have a couple of questions I am confused on:

Hi Jonathan,

I’d suggest taking a look at the playground that I periodically send out to swift-evolution showing the current state of the python interop.  I just sent an update to the "Python Interop with Swift 4+” thread just now.  It works with unmodified Xcode 9, but includes comments showing what code could look like with the proposal in question.

> 1) How do operators work with this?  I saw you give an example of a+b for python types, but I don’t see where either proposal bridges operators. (I could easily have missed it though)

As Magnus points out, Swift 4 already supports overloading operators with dynamic behavior.  In the case of the playground, it looks like this:

public func +(lhs: PyVal, rhs: PyVal) -> PyVal {
  return lhs.call(member: "__add__", args: rhs)
}

This has all the “bad behavior” that people are concerned about: it could fail at runtime.  Despite the claims, Swift does not actually make an effort to prevent this, and that is an intentional part of its design.

> 2) What if I need two separate python libraries?  The code says ‘let np = Python.import(“numpy”)’.  Are we supposed to make a separate variable for each import?

Yes, that is traditional for python, which would typically look like:

	import numpy as np
	import pandas as pd 
	import matplotlib.pyplot as plt

and the playground already supports (with no language extensions):

	let np = Python.import(“numpy”)
	let pd = Python.import(“pandas”)
	let plt = Python.import(“matplotlib.pyplot”)

It turns out that languages everywhere have standardized on starting with a block of imports :-)


> 3) How will inter-op between Swift types and Python types work?  It looks like you are just passing strings and integer constants to python functions. Do they get converted automatically, or do we have to explicitly convert them?  I am guessing this is using expressibleBy___ to work?

PyVal conforms to all of the ExpressibleBy protocols, so you can use literals with it freely.  You need an explicit (failable) conversion from a PyVal to Int (and other types that are PythonConvertible), and can use an explicit non-failable conversion from Int to PyVal if it is a variable.

The playground has a tutorial page which shows all this in action.

-Chris


> 
> Also, I would still really like to see a different coloring/styling for methods which fall down to this protocol.
> 
> Thanks,
> Jon
> 
> 
> 
>> On Dec 4, 2017, at 7:30 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
>> 
>>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution <swift-evolution at swift.org> wrote:
>>>> The first one, has no static type info, no compile time checking, it's not self documenting, no type inference so people will be forced to use a dynamic reference at the call site to store the result, leading to more type loss, and all this spirals down.
>>>> I'm already starting to fear dynamic.
>>>> Edit: The danger has passed (Phew!) ... and dynamic wasn't been abused after all, no need to down vote me after 3 years :)
>>> 
>>> From what I can gather, `dynamic` is used when declaring types, but there's no indication at call sites that what is being invoked is dynamic. And it even allows for casting basically anything to the `dynamic` type.
>>> 
>>> https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/dynamic
>>> 
>>> So here we have a language community that was (is?) very vocal about caution when it comes to type inference with `var`, but seems to have accepted the validity of `dynamic`. This seems to show that at least one community has absorbed this sort of change (arguably a more "dangerous" version than what is being proposed here) with no real issues.
>> 
>> Right.  dynamic in C# is far broader (and more “dangerous”) than what I’m proposing.  That said, because there have been absolutely zero specific examples of the sorts of harm DynamicMemberLookup could cause, it is difficult to speculate about exactly which boogieman people are afraid of.
>> 
>>> So I have a few questions:
>>> 
>>> - Would it be enough to require annotation of the dynamic nature of a type at the declaration sites, if that still means the call sites aren't explicitly annotated? 
>> 
>> It is impossible to solve a problem if it cannot be explained in enough detail to provide examples.  Personally, I don’t see the problem at all.
>> 
>>> - Why do some think the Swift community would be more at risk of abuse of this feature than the C# community seems to have been? 
>> 
>> 
>> People are making bizarre claims about what the spirit of Swift is, informing me of things which are obviously not true, and ignoring the evidence I present to them.  This is doubly humorous given that I have a fairly good sense for the design balance and tradeoffs of existing features in Swift today, along with detailed rationale for why they were added, when, and all of the discussion that backed them.  I chalk this up to the fear of the unknown or perhaps a mistrust for the peers these people work with.
>> 
>> My goal is to make the design and proposal writeup as good as possible, and the fear mongering about abuse has led me to add several options for further narrowing the potential for abuse, including to the point of requiring every new adoptee to go through the Swift evolution process for review.  During the review period for DynamicMemberLookup, people who carry these concerns are welcome to +1 one or more of those.
>> 
>> I personally am far more interested in getting to the bottom of Doug’s concerns - it isn’t clear to me what exactly his preferred direction actually is, but that discussion is based on engineering tradeoffs and may well lead to a change to the proposal or a complete change in direction.
>> 
>> -Chris
>> 
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171206/1c6df7e6/attachment.html>