> On Nov 11, 2017, at 10:33 AM, Chris Lattner via swift-evolution > <[email protected]> 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 “dynamic thing” protocol. These are all bad ideas > for reasons described in the thread. If you’re curious, I’m happy to > elaborate in alternatives considered. > > As such, discussion converged on pitching two proposals, which are generally > useful beyond this niche: > > 1. The dynamically callable one already written. > 2. A dynamically member lookupable proposal to sugar things like > foo.get(member: “bar”) - and the corresponding setter. >
One other pertinent thing from the discussion thread: it seriously isn’t lost on me how the Swift type checker works. One of the the alternate designs that I intend to explore is to add a second method to the protocol, to encapsulate the Swift member dispatch idiom: func dynamicCallMember(member: String, arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult This puts more effort onto the implementer of the protocol, but I think that is a totally acceptable tradeoff to save compiler complexity. -Chris
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
