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 <> wrote:
>> On Dec 7, 2017, at 11:29 AM, Letanyan Arumugam < 
>> <>> 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 
> (
> <>),
>  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 

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.

swift-evolution mailing list

Reply via email to