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

[Christopher Kornher]

> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution <swift-evolution at swift.org> wrote:
> 
> On 04.12.2017 19:27, Joe DeCapo via swift-evolution wrote:
>>> On Dec 4, 2017, at 10:08 AM, Benjamin G via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>>> 
>>> 1_ From what i understood from this discussion (please correct me if i'm wrong) python code is already callable from swift right now, without any modification to the compiler, but then the syntax to *some* very generic python function would just not be really pretty. If it's just library calls, we could just wrap those calls into pretty functions for our needs, but then :
>> I think it's worthwhile to add this syntactic sugar to make wrapper libraries easier to write and reason about. From Chris's example playground:
>> let d = np.call(member: "array", args: Python.array(6, 7, 8),
>>                 kwargs: [("dtype", "i2")])
>> // Python:        d = np.array([1, 2, 3], dtype="i2")
>> // Future Swift:  let d = np.array([6, 7, 8], dtype: "i2")
>> It's far easier (at least for me) to read the sugared Swift version and understand what it is doing than how it's currently required to be written.
> 
> Yes, it is easier to read, if you just wrote this. But not easier to understand when you are looking into some one's code during the debugging to try to understand what is not working exactly, where is the normal static code and where is next dynamic call.
> I strongly believe that dynamic code should not looks like normal "static" code in Swift, because this is not expected by *Swift* developer.  When we look on method name/property *we* expect it is defined somewhere, we can find definition, we know what rules are applied to that "object" like method or property.
> 
> I'll be glad if more people use Swift, I think that Python/Ruby/etc interop could be useful and we need ergonomic syntax for this, but I don't agree that we should change Swift to be more comfortable for non-Swift devs when this change complicates live of Swift devs.
> 
> Probably the correct way to have dynamic calls in Swift is to 'mark' such code with special flag and we need to find it. For example:
> 
> > // Python:        d = np.array([1, 2, 3], dtype="i2")
> > // Future Swift:  let d = np. at array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np at array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np:array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np.~array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np. at array([6, 7, 8], dtype: "i2")
> > // Future Swift:  let d = np."array"([6, 7, 8], dtype: "i2") // name of dynamic method is like just string, no any guarantee & we can have any needed symbol in string to express the details of target dynamic language(if needed)
> > // etc

Unless I am mistaken, an intelligent editor would have enough information to demarcate dynamic calls which would accomplish your objective without the need for a heavy-handed differentiated call syntax.

This is not relying upon tooling, it is allowing tooling to do what it is supposed to: augment the development experience in accordance with a developer’s needs.


> 
> Yes, IMO such code should be second class citizen in Swift.
> 
> AnyObject's dynamic calls are not available on Linux, so their existence for apple platforms is just a required feature to talk to ObjC runtime, with headers\annotations for available methods/props, tooling supports. So IMO we can't make our decisions regarding "true" dynamic code design based on how AnyObject's semi-dynamic calls are designed, IMO they are two separate things.
> 
> Vladimir.
> 
>> I'm sure it's true that people coming from a background in a dynamic language will initially write "bad" Swift code. When I first started writing Python, I wrote it like Swift/Objective-C/Bash. But eventually I learned more of the common idioms in Python and rewrote my code to use those idioms. This is a bridge to allow easy access to the vast number of libraries that currently exist in those dynamic language domains, and to ease the transition of the multitudes of those programmers into Swift.
>> From everything I've seen in the Swift community so far, I have faith that we collectively won't abuse this feature to the point that it poisons what Swift has achieved so far. And I'm not against some type of "guardrails" that help prevent unintentional misuse, but I'd like for it not to be so much as to be punishing to those that want to make use of the proposed features.
>> _______________________________________________
>> swift-evolution mailing list
>> swift-evolution at swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution