<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 &lt;<a href="mailto:swift@davedelong.com" class="">swift@davedelong.com</a>&gt; 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="">//&nbsp;References to overloads are resolved just like normal subscript lookup:<br class="">+//&nbsp;they are either contextually disambiguated or are invalid.<br class="">+struct&nbsp;Ambiguity&nbsp;:&nbsp;DynamicMemberLookupProtocol&nbsp;{<br class="">+ &nbsp;subscript(dynamicMember member:&nbsp;String)&nbsp;-&gt;&nbsp;Int&nbsp;{<br class="">+ &nbsp; &nbsp;return&nbsp;42<br class="">+ &nbsp;}<br class="">+ &nbsp;subscript(dynamicMember member:&nbsp;String)&nbsp;-&gt;&nbsp;Float&nbsp;{<br class="">+ &nbsp; &nbsp;return&nbsp;42<br class="">+ &nbsp;}<br class="">+}<br class="">+<br class="">+func&nbsp;testAmbiguity(a&nbsp;: Ambiguity) {<br class="">+ &nbsp;let&nbsp;_&nbsp;:&nbsp;Int&nbsp;=&nbsp;a.flexibility<br class="">+ &nbsp;let&nbsp;_&nbsp;:&nbsp;Float&nbsp;=&nbsp;a.dynamism<br class="">+ &nbsp;_&nbsp;=&nbsp;a.dynamism&nbsp;&nbsp;//&nbsp;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. &nbsp;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>