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

[Letanyan Arumugam]

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.

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.

Remember these errors have no meaning specific to "something doesn’t exist". It’s whatever we want them to mean. 
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.

I understand that this seems like an unnecessary hinderance, but most forms of security/protection is.

> On 07 Dec 2017, at 19:47, Joe DeCapo <snoogansbc at gmail.com> wrote:
> 
> 
>> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam <letanyan.a at gmail.com <mailto:letanyan.a at gmail.com>> wrote:
>> 
>> 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.
> 
> After rereading the post you linked to last night (https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20171204/042015.html>), 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.
> 
> - Calls that return Void
Opt in to unchecked behaviour and return a Void

> - Calls that return an optional

Return an optional of an optional if you wish.
Or throw a “doesntExist" and return an optional
Just return an optional and ignore the “doesn’t exist meaning” or have it imply either

However you want to model it do so

> - Calls that return an IUO
Opt in and return an IUO if thats the right design

> - Calls that throw
> - etc.
> 
> 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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20171207/015e5b7a/attachment.html>