> On Dec 4, 2017, at 1:12 PM, Vladimir.S via swift-evolution > <swift-evolution@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@swift.org <mailto:swift-evolution@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.@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.~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") // 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@swift.org >> https://lists.swift.org/mailman/listinfo/swift-evolution > _______________________________________________ > swift-evolution mailing list > swift-evolution@swift.org > https://lists.swift.org/mailman/listinfo/swift-evolution _______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
