BTW, Java via JNI would be another good application of this proposal. I once 
used a JNI wrapper library in C++ and it was pretty hairy and tedious.

I think we might want to declare a "Python object" as implementing swift 
protocols. If the methods that implement a protocol are NOT implemented in 
Swift, then the python code should be called -- the names already match. 
Otherwise the developer the has to map the protocol methods and properties to 
the Python methods, etc.

C. Keith Ray <- buy my book?
twitter: @ckeithray

On Dec 4, 2017, at 7:30 PM, Chris Lattner <> wrote:

>>> On Dec 4, 2017, at 5:22 PM, Joe DeCapo via swift-evolution 
>>> <> 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.
>> 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

Reply via email to