> On Nov 28, 2017, at 8:57 PM, Slava Pestov <spes...@apple.com> wrote:
> Hi Chris,
>> On Nov 28, 2017, at 8:54 PM, Chris Lattner via swift-evolution 
>> <swift-evolution@swift.org <mailto:swift-evolution@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:

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 

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?


swift-evolution mailing list

Reply via email to