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

[Vladimir.S]

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

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
>