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

[Brent Royal-Gordon]

Leaving the "should we do it at all" question aside…

> On Nov 10, 2017, at 9:37 AM, Chris Lattner via swift-evolution <swift-evolution at swift.org> wrote:
> 
> We propose introducing this protocol to the standard library:
> 
> protocol DynamicCallable {
>   associatedtype DynamicCallableArgument
>   associatedtype DynamicCallableResult
> 
>   func dynamicCall(arguments: [(String, DynamicCallableArgument)]) throws -> DynamicCallableResult
> }
> 
> It also extends the language such that function call syntax - when applied to a value of DynamicCallable type - is accepted and transformed into a call to the dynamicCall member. The dynamicCall method takes a list of tuples: the first element is the keyword label (or an empty string if absent) and the second value is the formal parameter specified at the call site.

I don't really like passing the argument names to the parameter list. Instead, I would prefer to see them handled in the member-resolution method. You don't give a design for DynamicMemberLookupProtocol here, but assuming that you're imagining that a call like this:

	foreignObject.someValue(keyword1: 42, "foo", keyword2: 19)

Would translate to something like this:

	foreignObject.dynamicMethodLookup(name: "someValue").dynamicCall(arguments: [("keyword1", 42), ("", "foo"), ("keyword2", 19)])

I would instead like it to look like this:

	foreignObject.dynamicMethodLookup(name: "someValue", arguments: ["keyword1", "", "keyword2"]).dynamicCall(arguments: [42, "foo", 19])

This would better suit languages like Squeak (or Swift!) where you cannot fully look up a method without its keywords. (Languages like Python would simply store the keywords inside the object returned by `dynamicMethodLookup`.) It would also allow you to use our "get-a-closure" syntax:

	let uncalledMethod = foreignObject.someValue(keyword1:_:keyword2:)

-- 
Brent Royal-Gordon
Architechies