<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class=""><div style="color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;"><div class="">So the idea is that we shouldn’t allow dynamic lookups and calls to return values without some sort of error handling by default. Avoiding error handling should be an opt in situation. The point of having the default behaviour require error handling is that these protocols will always have at least one failure to handle.</div><div class=""><br class=""></div><div class="">Dynamic calls would work in much the same way as a lookup. Calls should require that they return an Optional or throw by default. You can then opt in to have the ability to return whatever you want however you want.</div><div class=""><br class=""></div><div class="">Remember these errors have no meaning specific to "something doesn’t exist". It’s whatever we want them to mean. </div><div class="">However you want to model your call is up to you. If you want to just return Void, for whatever reason, opt in and do so just as long you are sure.</div><div class=""><br class=""></div><div class="">I understand that this seems like an unnecessary hinderance, but most forms of security/protection is.</div></div>
</div>
<div><br class=""><blockquote type="cite" class=""><div class="">On 07 Dec 2017, at 19:47, Joe DeCapo <<a href="mailto:snoogansbc@gmail.com" class="">snoogansbc@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><meta http-equiv="Content-Type" content="text/html; charset=us-ascii" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""><div class=""><blockquote type="cite" class=""><div class="">On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam <<a href="mailto:letanyan.a@gmail.com" class="">letanyan.a@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><span style="font-family: SourceCodePro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; float: none; display: inline !important;" class="">I think a better approach would still be to try and get the author of the type to make the right choice in the first place.</span></div></blockquote></div><br class=""><div class="">After rereading the post you linked to last night (<a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html</a>), I think it could quickly get out of hand. It might be simple enough for DynamicMemberLookup, but once we get to the point of discussing DynamicCallable there are many more variations.</div><div class=""><br class=""></div><div class="">- Calls that return Void</div></div></div></blockquote><div>Opt in to unchecked behaviour and return a Void</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">- Calls that return an optional</div></div></div></blockquote><br class=""><div>Return an optional of an optional if you wish.</div><div>Or throw a “doesntExist" and return an optional</div><div>Just return an optional and ignore the “doesn’t exist meaning” or have it imply either</div><div><br class=""></div><div>However you want to model it do so</div><br class=""><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">- Calls that return an IUO</div></div></div></blockquote><div>Opt in and return an IUO if thats the right design</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">- Calls that throw</div></div></div></blockquote><blockquote type="cite" class=""><div class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div class="">- etc.</div><div class=""><br class=""></div><div class="">I know this is a discussion about DynamicMemberLookup, but DynamicCallable is closely related and I imagine will end up following a similar pattern. How would you propose that DynamicCallable would be annotated in this fashion? There are a number of types of calls, and some are orthogonal so the combinations quickly add up. People will probably have similar concerns about failed call lookups as they do about member lookups.</div></div></div></blockquote></div><div class=""><br class=""></div><div class=""><br class=""></div></body></html>