Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Without commenting on anything else, I have encountered one use-case where it would be nice to be able to “call” an instance. And that is, while modeling some mathematics, I made a DifferentiableFunction type which stores a function and optionally a reference to another DifferentiableFunction (its

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 13, 2017, at 1:45 AM, Adrian Zubarev > wrote: > > Hello Chris, I have some questions about this passage: > > Before this proposal, the Swift language has two types that participate in > call syntax: functions and metatypes (for initialization).

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

To close the loop on this pitch, I’ve gotten a lot of useful feedback from the discussion. I’ll prepare a revised version and do pitch #2 when I have time, perhaps later this week. Thanks! -Chris > On Nov 10, 2017, at 9:37 AM, Chris Lattner wrote: > > Hello all, > > I

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hello Chris, I have some questions about this passage: Before this proposal, the Swift language has two types that participate in call syntax: functions and metatypes (for initialization). Neither of those may conform to protocols at the moment, so this introduces no possible ambiguity into

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 12, 2017, at 3:33 AM, Tino Heth via swift-evolution > wrote: > > > >> Am 11.11.2017 um 19:03 schrieb Chris Lattner > >: >> >>> Swift is quite flexible on what can act as a closure — would it be allowed >>> to

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

One last try at promoting code generators as an alternative means of importing…. It keeps the complexity out of the compiler and you are able to write the “importer” in the language being imported allowing it to leverage it’s meta data introspection directly. I’ve prepared a playground which

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > wrote: > > Opening up the compiler architecture to make custom importers easier to write > is a great solution to a ton of problems, including yours I think, without > adding complexity to the core

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> Am 11.11.2017 um 19:03 schrieb Chris Lattner : > >> Swift is quite flexible on what can act as a closure — would it be allowed >> to use a dynamic callable in that context? >> I guess forwarding of >> >> let closure: ([(String, Int)]) -> Int = DynamicCallableType() >> >>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 6:52 PM, Matthew Johnson wrote: In point of fact, Swift already has the feature you are referring to. It just spells it with square brackets instead of parentheses. A simple change to the punctuation character has much less point than

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 6:24 PM, Joe Groff wrote: >> In contrast, it does *not* seem like it would help with the problem of >> resolving members of “id” typed values in Objective-C, which is the crux of >> the dynamic language problem. If my understanding is correct, type >>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 11, 2017, at 5:27 PM, Chris Lattner wrote: > > Ok, which differences? > > -Chris > >> On Nov 11, 2017, at 2:19 PM, Matthew Johnson via swift-evolution >> wrote: >> >> >> >> Sent from my iPad >> >>> On Nov 11,

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Thanks for taking the time to respond. I think my confusion started from a misinterpretation that each method you're exposing from python would need a new implementation of the protocol. I've worked out my mistake, and you helped clarified with: > The system I’ve sketched out does not incorporate

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 1:57 PM, Chris Lattner wrote: > > > >>> On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution >>> wrote: >>> >>> so I don't think there's a time constraint forcing us to consider the >>> "narrow" vs "huge"

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 4:15 PM, Andrew Bennett wrote: > HI, this proposal looks really interesting! Thanks! > Clarity on the proposal's intent > Nice cheap bridges, or lowering barriers to bridging? The later: I’m not overly concerned about constant time performance: dynamic

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

In Java you can have annotation processors, user supplied compiler extensions, that are extensively used for making frameworks easier to use and for general interfacing to ‘foreign stuff’. Would a limited form of user supplied compiler extension be an alternative, an import processor. Special

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

HI, this proposal looks really interesting! I have a few questions: *Clarity on the proposal's intent* *Nice cheap bridges, or lowering barriers to bridging?* I can see this providing a nice quick interface to Python from Swift, but I'm not sure if the exposed interface will be very Swifty (you

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

That makes sense. I can see how type providers are very handy for that. I’m just curious how they help with the goal that this proposal is intended to address: being able to use arbitrary Python APIs from Swift. If the barrier to entry is the requirement for users to write type signatures for

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Ok, which differences? -Chris > On Nov 11, 2017, at 2:19 PM, Matthew Johnson via swift-evolution > wrote: > > > > Sent from my iPad > >> On Nov 11, 2017, at 11:40 AM, Chris Lattner wrote: >> >> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 11, 2017, at 11:40 AM, Chris Lattner wrote: > > On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution > wrote: On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

If it helps, for what I understand (in Typescript with things like http://definitelytyped.org ) the idea with type providers is that someone write the type definitions for dynamic code to basically provide a more "typed" version of the API that can be consumed in a more static language. On Sat,

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

They're called Blocks. Objective C has them. They're objects. They're actually Objective C objects. > On Nov 10, 2017, at 10:26 AM, Florent Vilmart via swift-evolution > wrote: > > Object that are functions too, Amazing! I wanted that in Javascript for a >

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:17 AM, Chris Lattner via swift-evolution > wrote: > >> so I don't think there's a time constraint forcing us to consider the >> "narrow" vs "huge" dimension. What's the best thing for the language and >> tools in the long term? This is a

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:52 AM, Xiaodi Wu wrote: > >> On Sat, Nov 11, 2017 at 12:39 PM, Joe Groff via swift-evolution >> wrote: >> >> >>> On Nov 11, 2017, at 10:12 AM, Chris Lattner wrote: >>> >>> On Nov 11, 2017, at 6:52

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Sat, Nov 11, 2017 at 12:39 PM, Joe Groff via swift-evolution < swift-evolution@swift.org> wrote: > > > On Nov 11, 2017, at 10:12 AM, Chris Lattner wrote: > > On Nov 11, 2017, at 6:52 AM, Joe Groff via swift-evolution < > swift-evolution@swift.org> wrote: > > I don't think

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:33 AM, Chris Lattner wrote: > > > >> On Nov 11, 2017, at 10:15 AM, Joe Groff via swift-evolution >> wrote: >> >> >> >>> On Nov 11, 2017, at 10:04 AM, Chris Lattner wrote: >>> >>> >>> > On Nov

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:12 AM, Chris Lattner wrote: > > On Nov 11, 2017, at 6:52 AM, Joe Groff via swift-evolution > wrote: I don't think it's that localized. It's going to make call resolution massively more complicated. Through

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:33 AM, Chris Lattner via swift-evolution > wrote: > > > The discussion phase in the previous thread considered several approaches, > including burning python specific support in, implementing a python importer, > and implementing a single

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 10:35 AM, John Holdsworth wrote: > Integration with Xcode would be straightforward but it’s been Android Studio > I’ve most experience with. For that it was just a case of adapting a gradle > plugin to add a rebuild phase. If you can’t automate it

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Integration with Xcode would be straightforward but it’s been Android Studio I’ve most experience with. For that it was just a case of adapting a gradle plugin to add a rebuild phase. If you can’t automate it running a generator when you change the surface of your api is not a big overhead.

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:15 AM, Joe Groff via swift-evolution > wrote: > > > > On Nov 11, 2017, at 10:04 AM, Chris Lattner > wrote: > >> >> >>> On Nov 11, 2017, at 6:29 AM, Joe Groff via swift-evolution >>>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 9:53 AM, Joe Groff via swift-evolution > wrote: > > > > On Nov 11, 2017, at 9:44 AM, John Holdsworth > wrote: > >> Isn’t there a third way? I wrote a bridge between Swift and Java

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 7:02 AM, Joe Groff via swift-evolution > wrote: > > > > On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution > > wrote: > >> >>> On Nov 10, 2017, at 6:12 PM, Slava

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 10:04 AM, Chris Lattner wrote: > > > >>> On Nov 11, 2017, at 6:29 AM, Joe Groff via swift-evolution >>> wrote: >>> >>> below the fold as far as the rest of the language is concerned. You could >>> just as well written

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 6:52 AM, Joe Groff via swift-evolution wrote: >>> I don't think it's that localized. It's going to make call resolution >>> massively more complicated. Through great pain and community anguish, we >>> pushed ourselves to a model where argument

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 6:29 AM, Joe Groff via swift-evolution > wrote: > >> below the fold as far as the rest of the language is concerned. You could >> just as well written what the importer synths up in Swift directly: >> >> func foo(bar: String) { >>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 2:19 AM, Tino Heth via swift-evolution > wrote: > >> Example Usage >> > > Swift is quite flexible on what can act as a closure — would it be allowed to > use a dynamic callable in that context? > I guess forwarding of > > let closure:

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 11, 2017, at 2:04 AM, Tino Heth via swift-evolution wrote: > I generally dislike „protocol magic“, but I think in this case, there is also > a precedence for an (imho) better way: > There’s no „Subscriptable“ protocol, and I would prefer callable types to be >

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 9:44 AM, John Holdsworth wrote: > > Isn’t there a third way? I wrote a bridge between Swift and Java without > having to > change the compiler at all by using a code generator to generate bridging > Swift > rather than having a Java importer.

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Isn’t there a third way? I wrote a bridge between Swift and Java without having to change the compiler at all by using a code generator to generate bridging Swift rather than having a Java importer. The script introspects the classes/packages you’re interested in using a script and generates code

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Very interesting indeed... class VehicleUtilities { int numberOfAxles(Vehicle v) { return 2;} // a plausible default int numberOfAxles (Truck t){ return 3;} } Vehicle v = new Truck(); VehicleUtilities u = new VehicleUtilities(); u.numberOfAxles(v); // returns 2 --> this is a nice

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution wrote: >>> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >>> > wrote: >>> > > People have reasonably asked for

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> Le 11 nov. 2017 à 16:48, Joe Groff via swift-evolution > a écrit : > > That'd be great, but Swift violates Gilad Bracha's golden rule by having > static overloading, and throws bidirectional type inference on top, so our > static name resolution can't be treated

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On 11 Nov 2017, at 16:02, Joe Groff via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution >> wrote: >> >> >>> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution >>>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 11, 2017, at 4:21 AM, Marcel Weiher wrote: > > > >> On Nov 10, 2017, at 19:04 , Joe Groff via swift-evolution >> wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; > > The

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

how does c code (and Python code, etc, other than ObjC) call Swift functions, methods, etc? C. Keith Ray https://leanpub.com/wepntk <- buy my book? http://agilesolutionspace.blogspot.com/ twitter: @ckeithray http://www.thirdfoundationsw.com/keith_ray_resume_2014_long.pdf > On Nov 11, 2017, at

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 8:35 PM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution >> wrote: >> >> >> >>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:44 PM, Chris Lattner wrote: > >> On Nov 10, 2017, at 11:42 AM, Joe Groff via swift-evolution >> wrote: On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution wrote:

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 4:20 PM, Joe Groff wrote: > > > >>> On Nov 10, 2017, at 4:12 PM, Charles Srstka >>> wrote: >>> >>> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: >>> >>> >>> > On Nov 10, 2017, at 3:45 PM, Charles

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 19:04 , Joe Groff via swift-evolution > wrote: > > I don't like the idea of some calls having wildly different semantics from > others; The obvious solution then is to make this proposal the general case and current calls a specialization of

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> Example Usage > Swift is quite flexible on what can act as a closure — would it be allowed to use a dynamic callable in that context? I guess forwarding of let closure: ([(String, Int)]) -> Int = DynamicCallableType() to the dynamicCall method of DynamicCallableType isn’t that hard, but

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

I generally dislike „protocol magic“, but I think in this case, there is also a precedence for an (imho) better way: There’s no „Subscriptable“ protocol, and I would prefer callable types to be handled in the same way (afaics, subscripts are already used as „callable with different braces“

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 9:10 PM, Brent Royal-Gordon > wrote: > Leaving the "should we do it at all" question aside… Thanks, most of the comments in this thread haven’t been constructive at all, I’m glad to get one that is :-) >> On Nov 10, 2017, at 9:37 AM, Chris Lattner

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Leaving the "should we do it at all" question aside… > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > We propose introducing this protocol to the standard library: > > protocol DynamicCallable { > associatedtype DynamicCallableArgument

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 6:12 PM, Slava Pestov via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution >> > wrote: >> >> Setting this aside, I’m very curious

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 10, 2017, at 6:05 PM, Slava Pestov via swift-evolution wrote: >> On Nov 10, 2017, at 6:01 PM, Chris Lattner wrote: >> >> It is. It is strictly sugar, as mentioned in the proposal. > > All new code has a cost. Indeed, I’m quite aware of

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution > wrote: > > Setting this aside, I’m very curious to hear whether type providers influence > your thinking after you’ve had a chance to look into them. I have always > thought they were very cool.

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 10, 2017, at 7:41 PM, Chris Lattner wrote: > > >> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >> wrote: >> People have reasonably asked for the ability to make their own

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 6:01 PM, Chris Lattner wrote: > > It is. It is strictly sugar, as mentioned in the proposal. All new code has a cost. > I do not expect any SIL or IRGen changes associated with this proposal, just > type checker changes. The type checker changes

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 10, 2017, at 5:51 PM, Slava Pestov via swift-evolution wrote: > Hi Chris, > >> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution >> > wrote: >> >> Hello all, >> >> I have a couple of

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:37 PM, Susan Cheng via swift-evolution > wrote: > > Hi all, > > I have few problems with this proposal. > > How we guarantee the arguments type are what we need? > If we passing the type to the dynamicCall that are not acceptable, what will

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hi Chris, > On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution > wrote: > > Hello all, > > I have a couple of proposals cooking in a quest to make Swift interoperate > with dynamically typed languages like Python better. Instead of baking in > hard

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 10, 2017, at 11:42 AM, Joe Groff via swift-evolution wrote: >> >>> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >>> wrote: >>> >>> This seems a really interesting solution Chris. >>> Similar to what Joe

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution > wrote: > >>> >>> People have reasonably asked for the ability to make their own >>> function-like types in the past, such that "myvalue(...)" behaves like >>> sugar for "myvalue.call(...)" or

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hi all, I have few problems with this proposal. How we guarantee the arguments type are what we need? If we passing the type to the dynamicCall that are not acceptable, what will happened? Should we always write the dynamicCall as a throwing function to check the precondition? Instead of

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 4:12 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: >> >> >> >>> On Nov 10, 2017, at 3:45 PM, Charles Srstka >>> wrote: >>> On Nov 10, 2017, at 5:36 PM, Joe

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:51 PM, Joe Groff wrote: > > > >> On Nov 10, 2017, at 3:45 PM, Charles Srstka > > wrote: >> >>> On Nov 10, 2017, at 5:36 PM, Joe Groff >> > wrote:

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 3:45 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 5:36 PM, Joe Groff wrote: >> >> How `MyObject.foo(_:bar:)` gets implemented is its own business, as far as >> the compiler is concerned. The compile-time name resolution

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 5:36 PM, Joe Groff wrote: > > How `MyObject.foo(_:bar:)` gets implemented is its own business, as far as > the compiler is concerned. The compile-time name resolution for the method > isn't impacted. > > -Joe The compile-time name resolution for the

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 3:27 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 2:57 PM, Joe Groff wrote: >> >>> On Nov 10, 2017, at 12:37 PM, Charles Srstka >>> wrote: >>> On Nov 10, 2017, at 12:04 PM, Joe Groff via

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 2:57 PM, Joe Groff wrote: > >> On Nov 10, 2017, at 12:37 PM, Charles Srstka > > wrote: >> >>> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution >>>

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:37 PM, Charles Srstka wrote: > >> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution >> wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; it's difficult

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:16 PM, Goffredo Marocchi wrote: > > > Sent from my iPhone > >> On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution >> wrote: >> >> Through great pain and community anguish, we pushed ourselves to a model >> where

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 12:04 PM, Joe Groff via swift-evolution > wrote: > > I don't like the idea of some calls having wildly different semantics from > others; it's difficult enough to tell what exactly a call might be doing > already. Since we also lack the more

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPhone > On 10 Nov 2017, at 19:42, Joe Groff via swift-evolution > wrote: > > Through great pain and community anguish, we pushed ourselves to a model > where argument labels are parts of the declaration name, not part of the call > argument Hey Joe,

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 11:20 AM, Chris Lattner via swift-evolution > wrote: > > >> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution >> wrote: >> >> This seems a really interesting solution Chris. >> Similar to what

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 1:19 PM, Chris Lattner via swift-evolution > wrote: > >> On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution >> > wrote: >>> Since we also lack the more obvious static

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 10:57 AM, Alejandro Martinez via swift-evolution > wrote: > > This seems a really interesting solution Chris. > Similar to what Joe mentions I think this would also be appreciated by > the community to make even nicer DSLs in Swift, which may or

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 10:51 AM, Joe Groff via swift-evolution > wrote: >> >>> Since we also lack the more obvious static "Callable" protocol idea to give >>> even well-typed call syntax to user-defined types, this also seems like >>> it'd be easily abused for that

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Sent from my iPad > On Nov 10, 2017, at 12:51 PM, Joe Groff via swift-evolution > wrote: > > > >> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: >> >> On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: >>> >>> I don't like

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

This seems a really interesting solution Chris. Similar to what Joe mentions I think this would also be appreciated by the community to make even nicer DSLs in Swift, which may or may not be a good side effect of the proposal. Also, I'm just wondering, how much complication adds this to the

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

> On Nov 10, 2017, at 10:41 AM, Chris Lattner wrote: > > On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: >> >> I don't like the idea of some calls having wildly different semantics from >> others; it's difficult enough to tell what exactly a call might be

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

On Nov 10, 2017, at 10:03 AM, Joe Groff wrote: > > I don't like the idea of some calls having wildly different semantics from > others; it's difficult enough to tell what exactly a call might be doing > already. This isn’t particularly useful feedback. Can you elaborate

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Object that are functions too, Amazing! I wanted that in Javascript for a while! On Nov 10, 2017, 1:04 PM -0500, Joe Groff via swift-evolution , wrote: > I don't like the idea of some calls having wildly different semantics from > others; it's difficult enough to tell

Re: [swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

I don't like the idea of some calls having wildly different semantics from others; it's difficult enough to tell what exactly a call might be doing already. Since we also lack the more obvious static "Callable" protocol idea to give even well-typed call syntax to user-defined types, this also

[swift-evolution] [Pitch] Introduce user-defined dynamically "callable" types

Hello all, I have a couple of proposals cooking in a quest to make Swift interoperate with dynamically typed languages like Python better. Instead of baking in hard coded support for one language or the other, I’m preferring to add a few small but general purpose capabilities to Swift. This