<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><br class=""><div><blockquote type="cite" class=""><div class="">On Nov 27, 2017, at 12:54 PM, Dave DeLong <<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="">Hi Chris,<br class=""><br class="">Some questions:<br class=""><br class="">1️⃣ How does the subscript approach work for dynamically passing in multiple parameters? For example, what would “dog.addTrick(“Roll Over”, favorite: true)” be when expressed as a subscript method? The subscript syntax only really seems to suit property-style invocations, unless I’m missing something obvious.<br class=""><br class="">2️⃣ It seems like “dog.add_trick(…)” would have a dynamic lookup name of “add_trick”. What would the lookup name of “dog.add(trick: …)” be? Or in other words, how do named parameters affect the lookup name?<br class=""></div></div></blockquote><div><br class=""></div><div>Hi Dave,</div><div><br class=""></div><div>Both of these questions are really about the other proposal, the DynamicCallable proposal:</div><div><a href="https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d" class="">https://gist.github.com/lattner/a6257f425f55fe39fd6ac7a2354d693d</a></div><div><br class=""></div><div>It isn’t as refined as the DynamicMemberLookup proposal, but the two do work together.</div><div><br class=""></div><div>DynamicMemberLookup is only about changing how “x.y” resolves.</div><div><br class=""></div><br class=""><blockquote type="cite" class=""><div class=""><div class="">3️⃣ Can I implement the subscript method multiple times, or is only a single implementation allowed? </div></div></blockquote><div><br class=""></div><div>Multiple implementations are allowed and are resolved through standard overload resolution. Here’s an extract from the test case in the patch:</div><div><br class=""></div><div><br class="">// References to overloads are resolved just like normal subscript lookup:<br class="">+// they are either contextually disambiguated or are invalid.<br class="">+struct Ambiguity : DynamicMemberLookupProtocol {<br class="">+ subscript(dynamicMember member: String) -> Int {<br class="">+ return 42<br class="">+ }<br class="">+ subscript(dynamicMember member: String) -> Float {<br class="">+ return 42<br class="">+ }<br class="">+}<br class="">+<br class="">+func testAmbiguity(a : Ambiguity) {<br class="">+ let _ : Int = a.flexibility<br class="">+ let _ : Float = a.dynamism<br class="">+ _ = a.dynamism // expected-error {{ambiguous use of 'subscript(dynamicMember:)'}}<br class="">+}<br class="">+</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div class="">For example, in the JSON example, there’s currently only a dynamic member subscript implementation that returns “JSON?”. Could I add another one that returns “String?” and have the type checker choose the appropriate one based on type inference?<br class=""></div></div></blockquote><div><br class=""></div>Yes. It is tricky to actually use such APIs, but they are definitely possible and work exactly like current overloads in Swift do.</div><div><br class=""><blockquote type="cite" class=""><div class=""><div class="">As far as naming goes, I’d propose “DynamicMemberForwarding”. In my mind, “Lookup” and “Resolve” are inappropriate, because you’re not actually “looking up” or “resolving” to a particular implementation. In Objective-C, the “+resolveInstanceMethod” stuff expects you to *provide* a method implementation (an IMP). On the other hand, if there isn’t a method implementation (which is the case here), you end up in the “-forwardInvocation:” path, where you can just introspect the NSInvocation and do whatever it is you’re doing to do. So, it seems like this proposal sounds a lot more like ObjC's “invocation forwarding” rather than the method resolution; hence my preference for using “Forwarding” in the name for naming consistency.<br class=""></div></div></blockquote></div><br class=""><div class="">Sure, I’m not strongly attached to any of the names in the proposal.</div><div class=""><br class=""></div><div class="">-Chris</div><div class=""><br class=""></div></body></html>