Sent from my iPad
> On Nov 11, 2017, at 5:27 PM, Chris Lattner <clatt...@nondot.org> wrote: > > Ok, which differences? > > -Chris > >> On Nov 11, 2017, at 2:19 PM, Matthew Johnson via swift-evolution >> <swift-evolution@swift.org> wrote: >> >> >> >> Sent from my iPad >> >>> On Nov 11, 2017, at 11:40 AM, Chris Lattner <sa...@nondot.org> wrote: >>> >>> On Nov 10, 2017, at 6:10 PM, Matthew Johnson via swift-evolution >>> <swift-evolution@swift.org> wrote: >>>>>> On Nov 10, 2017, at 11:25 AM, Matthew Johnson via swift-evolution >>>>>> <swift-evolution@swift.org> 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 something like that. In most cases, >>>>>>>> they still want to have type system control over what arguments and >>>>>>>> results their call operation produces. They don't really get that with >>>>>>>> this proposal; they lose all control over the arity and argument >>>>>>>> types. >>>>>>> >>>>>>> As I mentioned, this is directly addressed in the writeup. Here’s the >>>>>>> link: >>>>>>> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d#staticly-checking-for-exact-signatures >>>>>> >>>>>> That discusses why you didn’t include it in the present proposal but I >>>>>> think it’s reasonable to oppose adding a dynamic callable feature prior >>>>>> to a more Swifty static callable. >>>>> >>>>> Why? One does not preclude the other. >>>> >>>> For exactly the reason Joe articulates. Some people will use what the >>>> language offers to get the syntax they desire even if it sacrifices type >>>> safety. If we’re going to have first-class callable types in Swift (I >>>> think it’s a great idea) type safety for native code should be prioritized >>>> over syntactic convenience for dynamic language interop. We can have >>>> both, but the former should come first IMO. >>> >>> Hi Matthew, >>> >>> 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 the proposal >>> that I’m pitching. >> >> This is true if you squint, but I imagine a design for callable types would >> include some >> differences other than just punctuation. I think there was a pretty good discussion of this distinction in the SE-0021 timeframe. Specifically, subscripts model storage while callable would model functions. This means that subscripts can be used in a key path while callable would not (at last for now). On the other hand, I would want to see callables implicitly convert to a value of a compatible function type (possibly through a subtype relationship). Without this capability the syntactic illusion is only half complete. The callable feels like a function when used directly but not when it is assigned to a function type or passed elsewhere - it must be explicitly be wrapped in a closure and the arguments forwarded. First-class callable types are a syntactic sugar feature and as such if they exist they should be usable syntactically in all of the same ways functions are. Read-only subscripts are ok as a workaround in absence of first-class callable types (although I think in many ways just using `call` is better). Nevertheless, they are a workaround and can never be more than that because of the fundamental difference in what they model. Matthew >> >>> >>> -Chris >>> >>> >> _______________________________________________ >> 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
