[swift-evolution] Proposal: Introduce User-defined "Dynamic Member Lookup" Types

Chris Lattner clattner at nondot.org
Tue Nov 28 23:06:10 CST 2017

> On Nov 28, 2017, at 8:57 PM, Slava Pestov <spestov at apple.com> wrote:
> Hi Chris,
>> On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution <swift-evolution at swift.org <mailto:swift-evolution at swift.org>> wrote:
>> “post.author" always invokes the DynamicMemberLookupProtocol proposal.
>> “post.author()” would invoke the “DynamicCallableWithKeywordsToo” hook in the dynamic callable proposal:
>> https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d <https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d>
> Elsewhere in Swift, it is generally the case that
> foo.bar()
> is equivalent to
> let fn = foo.bar
> fn()

That’s not actually the generally the case once you include some keyword arguments in the call.  Recall that function types don’t have keyword argument labels any longer, so:

	foo.bar(x: 42)

Is not equivalent to:

	let fn = foo.bar
	fn(x: 42)

> Would this equivalence still hold with your proposal(s)?

It completely depends on the direction of the DynamicCallable proposal:
https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d <https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d>

In my original proposal, I had no hook for “DynamicCallableWithKeywordsToo”.  Feedback from the list was that people care about smalltalk derived languages (Ruby, Squeak, and yes, ObjC/Swift) and so I added this as a generalization.

That said, I’m not attached to it at all.  I can see the advantages of supporting these forms, but I can also see the concern that you’re observing.

I think that proponents for “DynamicCallableWithKeywordsToo” would say that Smalltalky languages (including Swift per the example above) do not provide the ability to separate out the base name, and those a bridge to those language can justifiably eject this concern.  In contrast, since Python *does* allow the substitution that you’re suggesting, its bridge absolutely would provide that capability.

In the end, it comes down to the cost benefit tradeoff we’ll have to weigh: how much generality and power is needed and can be justified?


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171128/164f1a0b/attachment.html>

More information about the swift-evolution mailing list